Do not name things with data type prefixes
clsAutoFactory. No. Instead: AutoFactory
Names should be what they are in the problem domain - autos in this case. How a thing is implemented - is it an array? a given class? an integer? etc. is not what's important, we can read code and the IDE is real smart. Writing code that is descriptive is the thing.
Unnecessary interfaces
There is no reason for any interfaces at this point. Just inherit from Auto class. Half the code goes away! Perhaps make it an abstract class and override methods as needed. I bet there is common code and/or default behavior.
In general interfaces are for giving unrelated classes similar behavior. A Parrot might implement the Idogable so it can bark like a dog even though a Parrot is not a Dog. But a BMW is an Auto.
I am implementing the factory method
You wrote a factory class not a factory method.
A factory method would be a method in some other class that does the factory thing. The code simple enough at this point that you could create a factory method - say a method in the Auto class; but I am not saying you should.
There are 3 "levels" of factory design which facilitates increasing construction complexity. i.e. factory method, factory (a simple class), and abstract factory for very complex things. The abstract factory may be appropriate if you were creating multiple auto makes with multiple models with multiple individual options; and perhaps different kinds like SUV, sports car, truck.
Ditto to what @JAD said
switch default
this is a perfect place for catching errors. If the default case is hit then obviously that model has not been implemented in your code. So capture that fact and let the user know.
Be more specific with auto instance names. model is too generic.
Not this:
IAuto model = factory.createModel(ModelType.Audi);
model.start();
model.stop();
but this:
IAuto myAudi = factory.createModel(ModelType.Audi);
myAudi.start();
myAudi.stop();