There are a few bugs on the Sun Developer Network at
http://bugs.sun.com related to HashMap deserialization. They have relatively few votes, and have not been resolved. As you noted, the deserialization mechanism is calling hashCode before having valid values. That's not good.
As an experiment, try eliminating any trace of Hibernate or JBoss code/libraries for your example code. Do straight up instances serializing and deserializing to a file -- using exactly the Player and Team instances you have now. I'd bet you'll still get the NullPointerException.
I strongly encourage you not to use the conditional calls to super.hashCode(), as you will lose the Set semantics. Once deserialization is done, your instances will almost certainly hash to a different value because they will have their name field value set later in the deserialization.
I have myself encountered a problem similar to yours and have implemented patched the platform classes HashMap/HashSet. I forwarded toy bug examples and an working patch to Sun on April 21, 2006, but they haven't responded yet.
The basis for the patch is an extension of one of the ideas posted for one of the HashSet/HashMap NullPointerException bugs posted at Sun. The variation I pursued ensures that serialization works with both overridden and non-overridden hashCodes, not just classes with hashCode() overridden.
In summary, the method is to hack the HashSet and HashMap platform classes to suspend the hashing, but collect the set instance in a list and call registerObject() for each. Then the validateObject() methods are called subsequent to the ordinary deserialization. HashMap thus implements ObjectInputValidation. If you roll your own patches along these lines, don't forget you'll need to use a switch such as -Xbootclasspathp: to override the default platform classes -- just putting patched classes in the regular CLASSPATH won't do it.
Ideally, Sun would have implemented serialization so that circular references work out of the box... but maybe they will revisit the problem. The failure to manage this case cleanly has probably caused a lot of mischief to those who believed "it should just work."
I am frankly surprised more Hibernaters haven't encountered this problem. Moving detached partial object graphs around is a wonderful Hibernate trick, but if one has only POJOs, it depends on serialization. Maybe this "use case" isn't common, perhaps individuals aren't creating many circular references on objects that have hashCode overridden... or maybe when people bonk, they abandon the approach, or work around it by trial and error.
If you'd like to see the care package I sent to Sun, which includes a source patch to work around the messy deserialization wrinkle, send me a note. The patch was designed to be just good enough to work until Sun resolved it, but that may be awhile... ;)
Ahem, something seems terribly broken in Java!