Possible solution 1: Smaller communities; Dunbar's number. I know it's been suggested before, but here it is again... When everybody knows everybody, people are nicer. Just create one unique, isolated instance of the site for every X number of users. Distribute current users randomly (or whatever) among the instances. Assign new users to the least populous instance. If an instance gets over max_number of users, split it in two.
Don't bother trying to do fancy stuff like connecting votes between communities; if something is really good people from each community will submit it separately. Also, it might be nice to be able to move between communities... but that sounds like something for version 2.
You could have these smaller communities run in parallel with the main site if this seems like too big of a shift.
Possible solution 2: Not sure if this really addresses the issue squarely -- but what if, when ranking stories and/or comments, you factor in the number of votes in the intersection between the current user and the submitter/commenter. Something like:
define votes(username): return ids of last n upvoted items for username
item_score *= (length(intersection(votes(user_x), votes(user_y))) / (n / 2))
Just use the original algorithm if the user hasn't yet cast n votes.
One man's garbage is another man's gold, as they say.
You could do something similar by checking downvotes as well. If two people are polar opposites (one person upvotes stuff the other downvotes), then comments by one could be greyed out or hidden for the other.
If there were simply a box I could check to make my votes public, then maybe somebody could write a Chrome or Firefox extension to pull this data and handle the re-ranking.
Neither of these two ideas would be perfect, but I think they would improve the user experience significantly. If nothing else they would be interesting experiments.