The point of a good error page is to apologize for the error, explain what happened in layman terms, what might be responsible for this, and what next steps to take.
error 500 rarely supplies a good explanation so the error page has to be vague. This results in users starting to refresh the page hoping it would miraculously render, even in cases of major botched up code deployments. Thus, you need to prevent such behavior with clear instructions on what to do next.
Telling your visitors, "The site is dead. You should give up," isn't a good practice. Users need to have some feeling of control & involvement into the situation, so give it to them by letting them send a message to the engineering team no matter how large or small it is. Then, once the site is back up email them (even generically) thanking for reporting the error & notifying of the resurrection.
The best sample design I've found so far is Goodbye, Old 500 Page on Think Vitamin (web.archive.org). You can also see error page examples from NetTuts+ (one and two) and Smashing Magazine (one). Search the page for
500 in all of them as they're in multiple locations.