What I want is to be able to configure a user's home page on the website with their choice & order of several widgets.
That sounds exactly like what I've (only*) read ASP.NET WebForms' "Web Parts" is for.
*I wouldn't know in practice; the place I work at never really learned ASP.NET, so they re-invented things like Web Parts and ASP.NET Membership.
after doing MVC the last 4 projects I'm thinking Yuck too with these code-behinds
Couldn't parse that of course, but it jogged my memory of something from an earlier discussion, where you said MVC was overkill for what you were doing, and after Slashdumb closed the discussion I was thinking the following. We've used ASP.NET MVC for our last three projects. Yet we haven't structured our code in the MVC pattern. The MVC pattern is just used by ASP.NET MVC framework, that we hook into. But really that's the same as WebForms. We don't architect our code to some kind of code-behind model, or say copy the Viewstate concept for anything else in our code. We just hook into the framework we're using, however it's been architected. Either way our application architectures are always (very poorly done) 3-tier ones.
p.s. We've stopped doing WebForms projects, so I've no idea if/how well that supports HTML5. Why I prefer ASP.NET MVC is the control over the HTML generated (which is especially important for jQuery-heavy UI's, like my immediate boss has grown accustomed to), and I started out web programming in now-classic ASP, so I had to learn how it really worked, sans WebForms' hiding of statelessness et al. (To me what WebForms hides from me, not to mention imposes on me (if you haven't been tripped up by the page life cycle, you haven't done anything really complex), is more trouble than it's worth. WebForms was intended to allow desktop application developers to make web apps without having to learn too much (the programming model is, intentionally, *very* similar to WinForms). So it doesn't at all apply to me (as a benefit).)