Depends on the game. COD does have player colliders. Some MMOs (like warcraft) have absolutely no player collisions, so multiple people can occupy the same space. In the former it allegedly creates tactical play (blocking a doorway), and the latter prevents griefing (big groups of people making the market place unreachable because they crowd around the entrance).
In terms of implementation, typically you have separate collider geometry that goes along with your player geometry. Usually it's less complex because it's only to detect if something is colliding with it, which doesn't need to be as detailed as the geometry that shows the wrinkles in your player's clothing. This would usually all be handled by a physics engine- Bullet/Havok/Physx etc.
In a demo fps from a game engine, it could be as simple as a capsule shape representing the player. The more complex the geometry, the harder/slower it is for the game engine to use it, so it's typically a mix of primitive shapes to cover the main areas of the body, probably more detailed geometry on the scene itself, usually excluding stuff like plants.
Grab free Unity3d (www.unity3d.com), and start in unityscript / js (move to c# when you feel more confident). Hang around the unity forums and use their questions and answers to answer your initial questions, and start following devs on twitter.
Oh, and in terms of your experience base, Unity is a great place to start learning. The good thing with engines is they're not bottom-up, they're top down. By that I mean, you get to start with a bunch of functional bits, and then start delving deeper into them as you learn more. So in a more traditional environment or building your own engine, you'd have to learn how meshes are organised, how to draw them on the GPU, how to write shaders, how all that basic stuff works, long before you can even draw a basic cube. This way round, you get to draw a cube (drag and drop practically) and then via c# and the Unity API, you can start looking deeper into it- playing with the array of vertices, tweak existing shaders. More importantly, you don't have to worry as much about the low-level stuff (if you don't want to), and can get straight on with the higher level stuff of actually writing games.
I picked it up about 2 years ago, coming from a c# programming background. If you know C#, then Unity is really easy, user friendly and a lot of fun.
In terms of producing a full blown indy game- you can absolutely do it in Unity free. Things only "obviously look like" unity because of the splash screen You do eventually find yourself wanting the pro features- I think the one feature that eventually pushed me over the edge into pro was the very detailed profiling tool that pro comes with- you can literally see which methods are eating the most cycles, etc.
Unity tends to favour component based rather than object oriented architecture- basically it makes things a lot easier when developing games and is fairly broadly adopted methodology in gamedev.
The community though is what really sets Unity apart- both in terms of helpful people on the Unity forums, Unity answers, and Twitter etc.