Well, there are loads of things that should be considered. If you don't really care for memory, you can leave the string Name attributes. I prefer having a name for all my objects as well, but it can eat away quite some memory if you have a million objects and each has a name of average length of 20 characters (which results in additional 20 MB of memory).
If you want a really good system that uses commands, I suggest that you create appropriate classes for it. Just using strings is alright for a smaller engine, but if you plan it to be extendable, I'd definitely go with additional classes such as Event, Command, etc.
The Properties thing is a good idea for a generic class, but I don't think you need it that much. Sure, it could make things easier and more dynamic but also more prone to bugs and logical errors (such as literally typing mistakes in the strings used as keys). You could use it for a data model or something like that.
As for the methods, not every object really needs an update method. I'll explain this a bit later. Same with Interact. Process sounds like a good idea, but I'm not sure exactly how you want this to work.
The last engine I have worked on is separated into 5 main parts. I have listed 6 parts here, because I never implemented a proper Menu Model.
Part 1: Static Data ModelThe Static Data Model is pretty much what one could call a database. If you know RMXP's scripts, then the static model would be pretty much the data classes in the RPG module. Also, this model doesn't need any update method. It's simply unnecessary. A static model should have a base class from which all other classes are derived.
Part 2: Dynamic Data ModelThe Dynamic Data Model represents the objects in the game. Those objects should reference Static Data objects which define their basic template data. Those two models will probably have a very similar inheritance structure. These objects should be able to provide an interface to the outside, but they shouldn't be able to actually do much on their own. This model would obviously have to be updated every frame.
Part 3: View ModelThese objects should be used to display the Dynamic Data Model. A GUI library would be the closest thing to a View Model. RMXP's sprites would be kind of close to this one, but IMO they are bloated. This is another model that would have to be updated every frame.
Part 4: Menu ModelThis one is obvious. Menu objects display information and data and allow the user to interact and change that information and data. From my personal experience to come up with a good Menu Model is difficult. To come up with a good and generic Menu Model is extremely difficult. This is a model that might not require updates all the time, but an update method might still be a good idea.
Part 5: Controller ModelControllers define and control how Dynamic Data objects behave and interact with each other. They should also handle user interactions. The scenes from RMXP are an alright example. The Sprite classes in RMXP are also Controllers, but they are kind of messed up. IMO a general Controller Model should be separated from a display Controller Model. Another object model that needs to be updated.
Part 6: System ModelThere are usually many small classes or general purpose classes that also need to be implemented. I like to call them System objects. Good examples of System classes would be:
Save Game Manager
Game Profile Manager
Scene/Game-Logic Mode Manager
Menu Manager
Map Position (a "Vector2" with x, y or "Vector3" with x, y, z could be used for this, but I had my reasons for a separate class, it's a long story)
Game Data (the object containing all the game data)
Generic Condition
Generic Condition Set
AI Module
Depending on what kind of object it is and what it does, it might or might not required an update method.
In the end, you should adapt your model to suit your needs rather than making an all-purpose engine. Cut down on properties and generic concepts if you don't need them or don't really see yourself actually using them in your engine. They can be just a waste of your time which you could have used to implement features that matter.
To me personally a similar structure was very useful as I was able to reuse loads of it for a new project. I've been working 8 working days on it for now and it's about 70% done. The full game will probably be done within 15 days of work. Sure, it's a quite simple game, but because I was able to define, separate and implement many useful concepts in MB, I already had loads of stuff already finished and ready to go so that this new game will take a ridiculously short amount of time to make.
If I didn't have all of that, I would have at least required another 15 days and the end result wouldn't have been as nice and systematical as this will be.
EDIT: BTW, I named my namespaces Database, GameObject, Scene and System. I then used a class Base in the first three to define a base object with all the common properties that are required for every object of that model. While Database::Base and GameObject::Base are quite simple, Scene::Base turned out actually quite complex yet not bloated. I was playing with the thought to rename the namespaces to Data and Game just to be able to write shorter, but namespace Game would probably mess with System::Game so I left it all as it was. Just throwing that thought out there. Maybe you can make something out of it.