It is possible – in fact, the Block Editor and any number of the @wordpress/ Gutenberg packages can be used stand-alone entirely outside of WordPress – but for the moment it’s quite a bit more of an involved process than the convenient wp_editor() function, and what exactly you’d need to do to make it work is heavily dependent on the specifics of your use-case.
You can see the process which WordPress uses to load the core Block-based Post Editor in /wp-admin/edit-form-blocks.php. There are a number of things which are dependent on loading in the dashboard environment, which means that requiring this file alone is unlikely to work on the front-end. But you could takes cues from this file in order to play around with loading the core post editor elsewhere.
Another option is to compose a number of the Block Editor’s components into a new React application. This tutorial is a bit out of date, but does a good job explaining the basic process (also see the associated repo). A simple example of a standalone editor in action is the Gutenberg repo’s “Playground” Storybook implementation – see the source here and the demo here. There are also a number of standalone implementations to be found on CodeSandbox.io.
If you wanted the front-end editor to be closely integrated with WordPress’s core data sources as it is on the dashboard, you might want to more closely inspect and replicate the core implementation from the @wordpress/edit-post package – if not play with loading it directly.
If you intend on presenting the editor to visitors, you might also experience permissions/capabilities issues, as visitors will not have the capabilities necessary to exchange data over the REST API as authenticated users do when working from the dashboard. To that end, it may be necessary to implement custom REST endpoints and custom @wordpress/data data-stores.