I'm not sure what part(s) you need help with. It sounds to me that you have an offset problem. For 3rd person views (over-the-shoulder), your character's position is a pivot point on a fixed camera with an offset. So, all movement and physics are centered around the player-character and the camera is at a certain offset (rotated by the rotation matrix) from that player-character...... Does this help? As I said, I'm not sure what you want.....

Always have options to change the directionality of the mouse axis' to accommodate different players' preferences. The same goes with keyboard bindings.

I see a lot of games today that don't let you change your controls. I will definitely try to implement that!

Which is most definitely wrong. If there's one thing you convey to other people making games please make it be that they should not follow suit in the same laziness that a lot of AAA developers show these days, especially in PC ports. Controls and options are one thing that it is almost always better to have more of, short of it being haphazard.

In particular right now so many companies have focused all their efforts on developing games for console to where it is rare for us to even get basic features like key rebinding on ports, i f they do feature that, there is usually a lot of other stuff broken.

So yes, please do!

Hello.
You're describing problems in two different areas: one is related to your game camera and the other is related to the player controls.

[subheading]Camera:[/subheading]

So, right now I have an empty for the body of the player, and an empty for the head of the player. Then I have a camera parented to the head object

[...]

When I rotate however, it looks like the 3d model is glued to the camera.

This behaviour is a direct consequence of parenting the camera to something controlled by the player.

The camera shouldn't be parented to the player character or one of its children. Instead, it should be controlled by a solver that tracks the player.
A possible definition for a solver is "a software routine that aims to solve a problem given a set of constraints."
Your "3rd person camera solver," a routine\method\function that you call each game tick to reposition and reorient your camera, could have the following constraints:

• If the player is standing still, centre the player character on screen.
• If the player is moving, centre on screen the point between the player character and a point ahead of the player in the direction that he's heading*.
• Prevent level geometry from occluding the player.
• Always mantain a certain distance from the player.
• Always use Ease-In and Ease-Out interpolation when transforming the camera

* This is a feature that is often overlooked in independent\smaller projects, but can be consistently seen in AAA games. It allows you to see "ahead" and anticipate obstacles. The player character is still on screen, but his focus is shared with an arbitrary point ahead of him in the direction that he's heading.
You do this by making the camera aim at exactly the average position between the player character and this point ahead of him. You interpolate between the player position in a manner such that when the player is not moving, the camera is solely focusing on him. The faster that the player moves, the more you focus on the average position between the player character and the arbirtrary point.
I have implemented this in a small demo that you can download here: http://www.gamedev.net/topic/650327-why-do-2d-games-have-main-character-locked-in-the-middle-of-the-screen/#entry5111055

[subheading]Controls:[/subheading]
I believe that by far what makes the most difference with controls is regarding the player input for movement as relative to the camera.
When you press the "move to the right" key, you transform the [1, 0, 0] 3D vector from the local space of the camera to the world space, and then proceed to move and orient the player character with the resulting world space vector.
A lot of games (especially console games) don't make use of "turn left" or "turn right" keys. Rather, there are only movement keys and when you move the player character, he turns to face the direction that you are moving him with.
In some games you can even steer the player character just by having him move forward and then orbiting the camera around him - this is evidence that the movement is relative to the camera.

This style of control is much more intuitive. Regardless of where your character may be facing, pressing "right" will make him turn to the right side of the camera (for the person playing, it's the "right side of the screen") and move in that direction.

I'm not sure if you're using Unity. This is demonstrated in their documentation for the "transform.TransformDirection()" method:
http://docs.unity3d.com/Documentation/ScriptReference/Transform.TransformDirection.html