I think that MVC, ASP and your favourite logging/exception handling framework can handle your goals quite nicely. ELMAH and Enterprise Library both provide easy to use exception handling and logging so pick your favourite .. I'm not going to go into the pros and cons of each here.
NOTE: you can't display a friendly error page AND return a HTTP 404 or 500 like your question suggests. When you return a friendly error page the HTTP code returned to your browser will be 302.This is a redirect to the friendly error page.
Friendly Error Pages
It sounds like you can achieve your goals by the good 'ol fashioned web.config settings that have been part of ASP.net for some time. You mention showing debug information when in dev and showing friendly pages in production. You can use the web.config's custom errors section for this (Set CustomErrors="Off" to show debug information). I'm going to assume that you are familiar with the CustomErrors attribute, if not read this:
If you need greater granularity of control over which error views you display, then use MVC's HandleError Attribute. This way you can choose different error views for each Action/Controller.
It sounds like you want to respond to all your exceptions in the same way ('Log errors and email them to administrator in production'). If this is the case your simplest option is to add code to
Application_Error(object sender, EventArgs e)
in your global.asax. This is where you can pass off to your chosen logging framework.
If you want more control over your exception logging / handling then you can subclass HandleErrorAttribute and override
this is another place where you can pass off to your chosen logging framework.
ASP.NET MVC HandleError
This gives you more control than the Application_Error technique mentioned above.
In general MVC gives you a great granularity of control over how to handle errors.
If you don't need this control then you can fall back on the ASP.net ways of doing things such as defining error pages on your web.config.