Do you think it is alright from architectural stand-point to have ViewModel - View without model for temporary things?
E.g.: I want users to input some paths so I can open some files later on. It doesn't make sense for me to store the paths anywhere just ViewModel and when the users clicks "Show all files" I then construct models of the files and ViewModels for View that represent them somehow. So really my only model is the model of the file.
Of course. If it suits your business process, why not.
But you could probably still use a model to have some sort of in-memory persistence of the entered paths.
Sure. There's no sense in moving the file-opening logic to a separate object just so that you can say you've done it.
I think sometimes people mistake Design and Architechtural patterns as hard and fast rules. We need to understand that these are just guidelines. One exampe of this could be the way different programming languages implement Singlton pattern.
So I would say if you need the functionality of View Model to be bound to View but really don't require a model, there shouldn't be any problem in ignoring the model. I would suggest use these patterns as guidelines and not as hard and fast rules. Feel free to make minor adjustments wherever applicable.
But at the same time keep in mind that you are not violating the purpose with which these layers are created. It should not happen like we bypass the model and start querrying the backend database directly from the View Model. As long as the basic principle of seperation of concerns is adhered to eerything should be fine.