I read a little more about your example - we would develop that in one app - each of those segments would be an "Area" which then consists of modules for specific functionality.
One slightly worrying thing I'm getting (possibly incorrectly) from your replies is that it sounds like your screens are closely tied to your functions. I.e. there one screen and only one screen for entering orders. I would view that as a bad thing because I often want to present several different views on the same function. An order might be entered by a customer, a salesmen in the customer's house, a telesales operator, a back end admin and so on. These guys all want the same business rules applied but what they need from a GUI is very different. A customer wants nicely presented pictures and customer reviews. A salesman might similarly want pictures (to show the customer) as well as a discount calculation. A back end admin probably wants a simple grid with as view keystrokes as possible and no whizzy bits. I'm sure you're already ahead of me on this but do a brother a favour confirm that you haven't ended up creating a single view per function. I'd hate that.

The other thing that's slightly worrying about your approach (but I don't think is a hard limitation, it could be worked around quite easily) is that it seems limited to providing a web UI. Could you consume this through a desktop or Mobile app? I imagine you could as the sprocs/services/whatever you use to expose the model could be consumed by a different UI. Is that right?

At first glance it sounds like your GUI is strongly coupled to your model and data but the more I look I'm not sure it is. You happen to have stored your GUI in the database but there's nothing intrinsic about that decision that couples them. Could you, for example, keep you GUI definitions in one DB and your business logic and data in another?

One other thing. In my experience sprocs tend to be inherently bad for unit testing. They don't decompose into nice small units and it's very difficult to mock their dependencies. Are you guys doing any form of unit testing (ideally TDD) and, if you are, how were you able to overcome these issues? (It's this, above all else, that makes me leery of sproc based systems so I'd love to hear how others have approached it).

Overall I think this sounds like a good approach. I can see some slight worries and niggles but none seem insurmountable and I can definitely see how it enables quick, RADish turn arounds.