Is that actually a good idea though? Leaderboard queries are likely to be the most common things you do with the data. You'd save a join by storing the username with the score data (as you'd never want one without the other), and it wouldn't save that much space by separating them given that usernames are only a few tens of bytes each.
That could be the name in a particular game or other data from the users profile. Or - limit the leaderboard by filtering on age, region or whatever.
Optimising a database for storage is really only a good idea when the additional redundant data is going to take up huge amounts of space. Storage is cheap. Making a query run faster isn't. Generally speaking you're better off optimising to reduce the number of joins and subqueries because they're the things that usually slow you down.
The way I like to approach performance issues like these is to cache or precompute de normalized data as needed, and make sure the master data is as clean and normalized as possible. You could have a materialized view, or a trigger that produced the denormalized version, or just store the data is Memcached.