Has been resolved in the end by removing the StartStoppable contract and introducing the more specific SchemaDefiner contract instead.

OK, nice. That works. Though you have to remember that all this Service(Registry(Aware)) notions are hard to grasp for an outsider.

In a local branch of mine, SchemaInitializer is a Service which can obtain a reference to the datastore provider by implementing ServiceRegistryAwareService. The SchemaInitializerInitiator contributes this service to the registry by instantiating the type retrieved via DatastoreProvider#getSchemaInitializerType(). I'm using this for the sequence initialization in Neo4j successfully.

Whatever. That's how ORM does or used to do it (linked to the SF lifecycle). But if you really want another interface go for it.
Your approach won't work I think though. The actual DatastoreProvider configuration + connection management is necessary. So it has to be injected somehow into this SchemaInitializer. It can't just be a Class.

Is the initialization/destruction of the schema necessarily tied to the session factory lifecycle? There might be cases which require to (re)-initialize the schema while an application is running; JPA 2.1 defines Persistence#generateSchema() which can be invoked in an ad-hoc fashion. Also I think whether to trigger schema initialization at SF start-up or not, should depend on the hibernate.hbm2ddl.auto setting.

So would an independent contract for schema initialization be more useful? It would provide hooks for creating/dropping all elements of the schema:

And be retrieved from the datastore provider and invoked at the right time:

This will move the decision when to invoke schema initialization/destruction and also the selection of the required contracts into core, leaving only the actual execution to the dialects.