For a framework such as PureMVC, or the MultiCore Pipes utility, for instance, have a look at the attendant unit tests and you'll see I'm dead serious about functional testing and making every possible assertion that I can think of to ensure that when used in the field, the framework or utility is going to hold water.
But for application development, you have a very different situation.
Often requirements are changing right up until the ship date. I certainly don't advocate it, but I work under these constraints everyday with most clients. This means that not only are you updating your code constantly, but you are also forced to update your tests constantly, and in a really large application it has a huge impact on velocity.
And unit tests are just as prone to error as the code they test. It's not like having unit tests for everything will absolve you of doing QA / Acceptance testing at the end anyway.
I think the important thing to cover (if your team has time for it) is the model. If the Model classes are not solid you will have problems throughout the rest of the application, there is no doubt about that. The View and Controller regions exist for the sole purpose of exposing the Model and letting you view or modify it. If the Model is broken, everything else will fail.
As for the application itself, depending on the language you're using, there are automated testing solutions that will drive the interface around. I built and ran a Y2K testing lab for Prodigy, and we used Mercury Interactive's Test Director to control a number of PCs running WinRunner automated testing software. For Flex, there is a Mercury QuickTest product, which works in a similar way (I think HP has bought them now). Our apps were browser based, and the software would record you clicking on buttons and typing things in. That would generate a script that you could modify and variablize for testing with various inputs. Then you could run batteries of these tests as often as you liked. This approach is essentially automating a QA tester's job, and allows for easy regression testing. It treats the whole app as a black box. It doesn't care what Command gets executed or what its return value is as long as the overall application behaves as the spec says it should.
But, I don't believe that automated testing is a panacea either, because an incentivized QA individual gets paid for finding ways to break your app. This person will discover the truly horrible things that will happen in the field, that you'll never think to put into your unit tests.
Therefore, I don't think that the time spent writing and rewriting unit tests for every view component, Mediator or Command has an acceptable payoff for the time and effort required to implement and maintain them. It is a whole separate legacy codebase that will have to be maintained going into the future, and that is something that clients are rarely interested in investing in.
I know that there is a huge faction of developers out there who have been trained to think TDD, and more power to them, but I have never had a client tell me that they wished I'd spent more time unit testing and less time delivering actual functionality. And I've never convinced a client that my unit tests were so solid that they didn't need to do thorough QA testing before shipping it. Tests make the developer feel warm and fuzzy, but you need to think about the cost to the client (if you are a contractor) or to your employer when you set about implementing your application testing approach.