This kinda depends on your definition of "Zero Downtime" -- A split->upgrade->fail-over->recovery scenario can be accomplished pretty easily by setting up replication between your two SQL servers, which also gives you the benefit of redundancy.
This works very similarly to what you describe above: When you do an upgrade you split your replication pair & upgrade one of them (along with a few app servers), switch the load to the upgraded set of machines, then upgrade the others and re-establish replication. The caveat is you will probably still need to stop accepting changes (inserts/updates) during the upgrade window (at least until the upgraded servers are running), otherwise you'll wind up with a split-brain scenario where you have changes on the "old" system that will be lost in the "new" one.
Depending on the kind of schema changes you're talking about & how well-written your application is you may be able to do some changes without downtime (adding new tables/views, adding a column, etc. can often be done without an outage, provided your app doesn't freak out when the number of columns in a table changes).
My suggestion to you is that you insist on an adequate maintenance windows for all changes/upgrades, to include outage time if necessary. Very few systems need to be truly 24x7x365, and if you wind up with an unexpected problem it's always better for the system to be offline with enough time for you to fix the problem or revert your changes than to be rushing through a fix with angry users breathing down your neck because they weren't expecting an outage...