Not bad. Obviously this is over simplified and doesn't really even begin to touch on any of the pain points of MVVM and their solutions, but for someone new to the pattern it shows the various parts. The only real complaint on that front is that while you created a MemoModel to illustrate the Model in MVVM, you didn't use it anywhere. For someone new to the pattern, there's absolutely no explanation/illustration of why there are three components involved in this pattern.
I don't like the Enabled property on your command. This externalizes something that shouldn't be externalized. This means anyone can turn the command on and off, and such code is very likely to lead to buggy implementations.
I'm confused about why MainPage is used as a shell for the View and doesn't itself follow the MVVM pattern?
In MemoViewModel.MemoText the code that enables/disables the SaveCommand (see point 1) should have been placed inside the first if statement. There's no reason to update the command if the property wasn't updated.
It's safer and more efficient to initialize the SaveCommand in the constructor rather than lazily initializing it in the property getter.
Minor point, but OnPropertyChanged isn't thread safe. Proper implementation of code that raises an event first assigns the event to a temporary delegate and then uses the temporary when checking for null and raising the event. In this case it might not be necessary, because technically ViewModels should have the same thread affinity as the View (i.e. it should behave the same way as, or possibly even inherit from, DispatcherObject). Therefore OnPropertyChanged should only ever be called from a single thread. Still, implementations like you showed always pop out at me as being incorrect.