I'm sure you'll be aware of the different MVC frameworks currently out there on the web.  RubyOnRails, MonoRail, and the new Microsoft ASP.NET MVC framework all claim to accelerate web development by removing a lot of the mundane, monkey-work plumbing involved in creating a web project.

They also provide a clear separation of concerns, by separating the presentation, logic and data-access into discrete layers.  This has the advantage that we can then introduce unit-testing into our web project, and mock any required components.

So far so good, but personally having looked at these frameworks, I can't fit them into any projects I'm working on at the moment.  It seems to me to be a trade-off between how much control I need and how much it conforms to a typical web layout.  But that's maybe because I haven't actually tried them out on anything other than a sample project. 

Having said that I do like what they offer - GETTING THE CODE OUT OF THE PAGE. 

Essentially, I believe we can achieve this and also maintain a lot of the control by using the framework outlined below.

As you can see, we have our MVC-triad, with the Controller at the heart.  The Controller interacts with the View via an interface, with each concrete WebPage having a reference to the Controller.  The WebPage also CREATES the Controller object(s) it uses, passing itself (it's interface) in to the Controller's constructor.   When the User selects something on a Page, the Page then calls the required method on the Controller.  The Controller can then carry out any logic and indirectly navigate to another URL.  It does this via the View interface that it has passed to it in it's constructor.

This example shows how the Controller can be used to control application flow.  The user initiates a command on MainPage, which calls Controller.Do_Command1.  In this method, the Controller would then carry out any logic for that Command, but then wants to move to another page.  The Controller can't do this directly, so calls the Show_AnotherPage() method on IMainPage (the MainPage's view interface).  The concrete MainPage class then redirects to AnotherPage.

This example shows the Controller again controlling the application flow, this time with conditions.  You can see how this could be easily tested via mocking.

Admittedly, this framework still relies on the developer putting in a lot of the plumbing, which has been nicely encapsulated by other MVC frameworks.  However, with this you get complete control over what is happening, and you also get to use the traditional WebForms approach, complete with Viewstate et. al. which is essential for 'legacy' apps.  It also means you can pick and choose the areas in the project where you implement it. 

If I was starting a web app from scratch I'd certainly look into MVC ASP.NET and see how it would work, but if you want the benefits of code separation in your existing applications now, then this framework could be adapted very easily.

EDIT: I'm not sure I really would look into MS' MVC ASP.NET framework any more - I can't see what benefits I would get from it that I can't with this approach.