Everything you've said is technically correct, but I'd try to approach the design pattern in a more abstract way and think about what it's trying to solve. MVVM is trying to solve the problem of providing separation between the view and model as well as providing two-way binding (i.e. pulling data from a model and presenting it, as well as taking user input and saving that back to the model).
Most patterns will want to separate the View and the Model, so that's still the same in MVVM, but what is more murky is how to convert/format the data for display to the user, and how to convert user input into your model. In many MVC frameworks, the presentation of model data in the view is handled pretty well, but you're usually on your own for taking user input and converting back into the model cleanly. MVVM aims to handle both.
Microsoft has chosen to do that using things like DependencyProperty, ICommand and ValueConverters. The basic idea is that your View will only be loosely attached to the ViewModel through bindings, so in theory you could reuse ViewModels with other views. This goes the same in the other direction (this clean two-way binding is what makes MVVM different from MVC, for example) in that your VM can notify that a property has changed (that's why you must implement INotifyPropertyChanged), but the VM has no idea if a view is there to react or not. That makes it very straightforward when you want to reuse these components.
So knowing what MS is trying to solve with MVVM, you can hopefully better understand why things like INotifyPropertyChanged exists or what ICommand is for and hopefully make good use of the MVVM pattern.