The quick solution is to scale up your current linode package, however, I think you might find that your traffic is going to peak and will wane next week after everyone has gone back to school/work and is out of the holiday mindset at which point you can scale back.
Put in a throttle - /proc/loadavg
Limit it to X signups per hour, asking them to check back next hour. Collect email and notify when they can sign up. Point them at a facebook page, ask them to like the page, do announcements when the next 'batch' of users is able to sign up.
If you want some help analyzing the slow query logs and/or the normal logs, email me a url of a .gz/.bz2 of a reasonable snippet at email@example.com.
Since you're running nginx, consider doing an alias and use proxy caching. I would doubt your static files are causing too many issues, but, if you can cache computationally expensive pages a little, that can help.
That said, if you're selecting more than 5% or so of the rows in a table, you're probably better off not using an index.
Another random tip. There is a world of difference between putting indexes on 2 fields, and putting a composite index on 2 fields. If you have restrictive conditions on 2 fields, MySQL has to work with the entire list of rows that match at least one of those conditions. (I don't know whether MySQL has the trick of joining indexes together before looking at rows, but even if it does it has to work with a list of rows matching the condition.) By contrast with a composite index MySQL can only look at rows that match both conditions. Much more efficient.
Good sets of additional tips/things to keep an eye out for.