You would have to register it with Autofac, which can be done by either creating a class that derives from
Module (in the Autofac namespace) and register your component, or to have it automatically discovered and registered, by creating an interface for your view model that derives from
IDependency.

However, why would you want to resolve an instance of your view model via Autofac? That seems pretty unconventional.

How would you, as a next step, manually resolve an instance (without constructor/property injection)? As I understand, I would need Autofac's ContainerBuilder and use a Scope? But when injecting the IContainerBuilder via the driver's constructor, I cannot find
the expected Resolve method and I am stuck.

I was using Microsoft PRISM a lot, where most of the participating objects are created by the container, also the view models. The view models in PRISM tend to get very complex and have more dependencies, maybe that's why I thought it could make sense.

But here, I understand after your post that my strategy might not be so good. Maybe it is a better idea to resolve the view model's dependencies in the driver class and pass them via constructor to the view model to avoid using the container for constructing
the view model.

Once your type is registered with Autofac, you can resolve instances of it using
WorkContext, which you can get via IOrchardServices or via
IWorkContextAccessor. WorkContext has a method called
Resolve<T>.

What I typically see with ASP.NET MVC view models is that they tend to contain all the data they need for the view. Preparing this data happens in the controller layer, where various services are resolved and queried. So you wouldn't actually pass these services
to the view model. Instead, invoke those services and store whatever data you need for the view in the view model.