From what I can see, you've posted a perfectly valid example of the Factory Method pattern:
- Both Device1 and Device2 inherit/implement the Device class/interface - polymorphism is still a key aspect of this example.
- You're using the Factory Method to encapsulate the logic to determine which concrete class to instantiate and return.
- The caller of the factory method remains nicely ignorant of the concrete classes involved - he just knows he gets back a Device. Which is exactly what you want a Factory Method to do for you.
It's true, the internal implementation is a little heavy-handed (switch-case). However, that doesn't make it any less of a true Factory Method pattern.
I don't really see where your example "isn't based on polymorphism" nor where it "breaks the open/closed principle". If I've missed the point entirely, feel free to update your post, to help us zero in on your question.
Now if the Factory method was taking the passed deviceName, and using it to find an exact match of the concrete class to instantiate (using reflection), that would absolutely break the Factory Method pattern, because the caller would have to have intimate knowledge of the different concrete classes. But as currently written, the passed deviceName is just a piece of data used in the decision-making process - it doesn't break the encapsulation of the factory pattern.