A lot of people have a class they define called "component" which is a simpler more flexible entity than the XNA GameComponent. Really hardly anyone uses GameComponents anymore, they are a kind of left over from when Microsoft ware trying to make XNA handle all the SceneGraph and Screen management itself rather than have the programmer develop his own system.
You should really make your own. Not only will it be better trimmed down to fit your needs, but you can also make it more flexible as a result of it's simplicity if that's your goal.
There are several different "Game Engine" tutorials out there that demonstrate such systems for managing multiple objects. Most of them have a root engine that updates and draws Screen objects in some order according to some criteria. While the Screens update and draw their Component objects when it is drawn and updated (respectively). Further some engine allow for Components to own Components which they manage and the chain goes on from there. The Component class is extended six ways from Sunday to represent everything from sprites to particle systems, to shader effects to AI entities, to space trees (octree/quadtree). really everything the player interacts with directly or indirectly within a screen is an extension of a component.
here are a couple game engine tutorial series I ran into just skimming google
http://www.innovativegames.net/blog/category/game-engine-tutorial/
http://roecode.wordpress.com/xna-gameengine-development-series/
I am aware that those are by the same guy, but it appears of all people making game skeletons in XNA this guy is the only one who is telling people how hw does it.