I am not sure if I get the point of the ServerModels. One would need to maintain the properties in both the ViewModel and the ServerModel, write logic for syncing them and so on. It also goes against the principle of "one-true-source" of data.
I can see that you don`t want to mix up your view-specific properties with your rest-data, but I feel that one might find a better solution for this problem.<p>On the application I am currently working on we choose the following approach to the problem( were using reflux for Flux implementations, main difference is that actions dispatches them self).<p>View -> Trigger Action -> Action Creator -> Action creator calls Rest API -> Action sent to Store -> Store receives REST data and creates Immutable versions of it -> Store Triggers immutable version of it`s content to view<p>This keeps the stores as the "one-true-source" while the action creators does all the communications against the rest-api. Might be that this approach will be to simple when the application is starting to really expand, but I feel we found an easy to maintain, easy to understand and clean solution to the problem.