I guess you're asking in the context of the Microsoft world?
It was my understanding that MVP was mainly employed for unit testing the controllers of the application. I think another term for the MVP pattern is Supervising Presenter.
The view in this case would be the ASP Page, which would have an instance of the Presenter, and any events in the page (click handler's for example) would delegate their work to the Presenter. The Presenter would have a reference to the View (although, through an IView interface that the Page would implement). The Presenter would then respond to actions from the View, do something, update the model and pass it back to the view or perform actions on the View via the interface.
This aids unit testing, because the Presenter (where any presentation logic should be) can have the view mocked out. Typically a Presenter would also have references to other services, which should rely on dependency injection (via constructor injection IMO) to also allow for the Presenter to be tested in isolation (a proper unit test).
The main reason I think to use MVP in ASP.NET WebForms is because the Page class is tied to the ASP.NET runtime, whereas because ASP.NET MVC has abstractions on things like the HttpRequest, and the controller and ActionResult classes can be tested in isolation, you don't need to employ MVP - it's unit testable by default.
So to answer (I think): I'd use MVP if I was using WebForms, to aid testability. Otherwise I'd use MVC.
Also check out the Web Client Software Factory, which offers a framework for a starter point for implementing the MVP pattern.
I was thinking of something like this.
Where "Webforms User Stuff" would depend on System.Web.Security and "Generic User Stuff" would have your flavor of access control. Don't directly use ASP.NET membership but use composition.
Best Answer
This isn't a bad way to go about rewriting an application. This would be particularly useful for a long term rewrite happening in phases:
Add a "test project" that utilizes CodedUI tests (or Watin or Selenium) to test the WebForms application through the browser. You could also use SpecFlow to define your test cases. I've used this to great affect on a WebForms application.
After you have good test coverage of the WebForms application, you can begin the next phase of refactoring: Moving common components into a separate class library. This is where your models and data access layer could be created. You can add a reference to this library to your WebForms applications. The tests you wrote in phase 1 make sure you don't break existing business rules
Port functionality over to your MVC application, modifying your tests to use the MVC app not the WebForms app.
Steps 1 and 2 could be tackled simultaneously. You can even start on Step 3 once you have an entire feature tested, and its common components are decoupled from the WebForms application.
Split the work out into main features. Once a feature is supported in the MVC application, shut it down in the WebForms application. It will eventually become a hollowed out husk of its former self until you can remove the code all together.