The way the activewarehouse manages views is not too bad and might be worth a look for you own work. The annoying part is when have change the view you have to drop and recreate in a migration which is messy.
Views and stored procs are just not The Rails Way for the moment. So its best to not try to be something radically different than the other adapters to support them and risk large adapter breakage with new versions of Rails.

The column reflection and usage of a view as a table works fine and has done well enough in the past actually. Your additions of the view insertion certainly gives them even more scope for usage in an app.
But it becomes a question of management of them once you start using them. The primary issue being dumping to schema so your test environment can work seamlessly with them rather than as special case.
If you have a look at the AR schema dumper you will see that it only dumps the return from the connections tables method. So to be able to dump views you have to hook into that or monkey patch the schema dumper to include the views.
However dumping a view is very different than dumping a table when using the ruby dumper. This is because it requires an SQL statement to define it rather than just column definitions.
There is also the issue of the rubyish way of defining the views for creation in a migration. The project I mentioned does satisfy these requirements to fully support them.
Its really a matter of how deep we want to support views. We can just stop here and leave the developer to manage the creation of them in their test database. Or go the whole way and make views first class AR objects with full migration support.

Good point. I can’t think of a reason, unless I am missing some possible interaction. Probably could be simplified otherwise.