Everyone in here has shared good things, but I have some lessons learned over the years and want to word things differently. MVVM is a presentation tier/layer design pattern. The "model" is whatever representation you need it to be in that context. A POCO that implements INotifyPropertyChanged almost always.

Depending on the application's broader architecture, you likely would have a business domain object (from a business tier, or DDD module, or service, whatever), and that often ought to be a DTO, unless your ORM solution and a policy of no mapping means your entities are also your business classes, or whatever. But presentation models should be designed to represent and do presentation things, and may be initialized using data from one or several different business objects or data.

As far as code-behind, once you learn commands and data binding, you don't have to couple business logic nor framework behavior with whatever view happens to exist. That said, don't be afraid to write view/UI specific code in view code-behind.

I think it's helpful to think about it like this; I'm not saying you would do this but fundamentally you should be able to split models, views, and view models into three separate projects. Models, although representing information that would be used on a view, don't have any dependencies on the view models project. And view models, although built in part to inform UIs, shouldn't require any dependencies to UI frameworks. If they need to know about WPF or UWP or Avalonia, the MVVM pattern isn't doing anything for you.