This may not answer everything you are asking, but it's too much for a comment.
Your solution's organization (I use the term organization rather than architecture) should reflect how you use it. It should be efficient for your use. For instance, when you want to make a change to a Menu does a developer have to open files from View/Menus and also from ViewModels/Menus to make the change? (This is inefficient.) Or do you have designers who only ever open Views, and developers who only ever open ViewModels?
This is why single team projects might prefer a feature-oriented approach (with related Views and View Models in the same feature folder) whereas large projects with multiple teams might prefer a component-oriented approach like your current structure. (This may also be the reason for Conway's law.)
I make a distinction (at least mentally) between Utilities and Infrastructure. Infrastructure code is a core part of your application's inner workings that is used by policy (e.g. "We always use RelayCommand on these WPF controls." -- UI Infrastructure). Whereas Utilities are generally useful purpose-built functions like perhaps FileOperations. I'm not suggesting that you create a new Infrastructure project or rename anything. Just make sure that all your "must use" components are in a highly accessible place, which it sounds like they are.
Utility code is at greatest risk for being forgotten or ignored. So make sure that what you put there is truly useful and time-saving. If you pollute it with a lot of minor helpers, other developers will not take the time to familiarize themselves with it and miss the opportunity to save time.
And then there are Helpers which are what I deem reusable code which is helpful across a few specific components. Maybe it's shared code used for related features. I generally keep these close to the calling code if possible and not in Utilities. This way, the code is not far off when a developer needs to work on that feature, and it doesn't add cruft to the more highly-reusable Utilities.
I look at it like: developers must be familiar with Infrastructure, should be familiar with Utilities, and may be familiar with a given feature's Helpers (if they work on that feature).
In general, your view model should be implementing INotifyPropertyChanged. It should then fire the PropertyChanged event whenever a property that the view is listening changes, and this will be picked up by the WPF framework. As you suspect, ObservableCollection is only for when you have a collection of things you want to monitor.
Best Answer
The Model is meant to represent both the current state of the data and the data access layer that represents the content. So, if you were using a database, you would handle read/write calls there. In that same vein, you should do disk reads and writes in your model (or, at least I would).