A session id is a temporary password which is usually linked to a username. Anonymous sessions are also useful tools in some cases.
Storing the username on the client serves no useful purpose. If the server trusted this information then it anyone could gain control by changing their username cookie to 'admin' or root'. Hence the session id does identify the user as well as proving the state of authentication, but only via an indirect lookup stored on the server.
In addition to anonymous sessions, it's also worth noting that the session data may be more than just a username and authentication state - it may also contain authorization information (e.g. roles) user preferences and (within bounds) transactional information. Storing information securely is not easily done on a substrate which is not protected against tampering.
I don't understand how you think this makes session hijacking / fixation more difficult; you've not explained why and you have some misconceptions about the way sessions work.
Certainly if the cookie data was trustworthy, then it would be easy to associate the true identify of an attacker with the http requests however the data is NOT to be trusted.
There are other ways to map identities to requests at the webserver - most SSO implementations provide for populating the webservers notion of the authenticated user. The information can be pushed up from the application (e.g. mod_auth_memcookie) or indirectly via other vectors such as supercookies and browser fingerprinting.