Yes AG support multiple subnets as described here. Also make sure that your data provider supports MultiSubnetFailover .. .NET Framework 4 supports it.
To answer your question ...
IF you use .NET framework 4 or 3.5 then the provider will support it as described here.
Also, a good reference to SQL Server Multi-Subnet Clustering is well documented.
With legacy client libraries or third party data providers, you cannot use the MultiSubnetFailover parameter in your connection string. To help ensure that your client application works optimally with multi-subnet FCI in SQL Server 2012, try to adjust the connection timeout in the client connection string by 21 seconds for each additional IP address. This ensures that the client’s reconnection attempt does not timeout before it is able to cycle through all IP addresses in your multi-subnet FCI.
The scenario is called out and supported on the link you've provided.
Availability Group with One Remote Secondary Replica
If you have deployed an availability group only for disaster recovery, you may need to fail over the availability group to an asynchronous-commit secondary replica. Such configuration is illustrated by the following figure:
Availability Group Upgrade in DR Scenario
In this situation, you must fail over the availability group to the asynchronous-commit secondary replica during the rolling upgrade/update. To prevent data loss, change the commit mode to synchronous commit and wait for the secondary replica to be synchronized before you fail over the availability group. Therefore, the rolling upgrade/update process may look as follows:
1.Upgrade/update the remote server
2.Change the commit mode to synchronous commit
3.Wait until synchronization state is SYNCHRONIZED
4.Fail over the availability group to the remote site
5.Upgrade/update the local (primary site) server
6.Fail over the availability group to the primary site
7.Change the commit mode to asynchronous commit
Best Answer
2 Massive questions
You haven't said anything about what is connecting to your databases.
For swapping over the databases log shipping will give you a much shorter cutover time than backup & restore.
If you can add a AOAG Listener with the name of the old server you will simplify updating all of the client connection strings (means the old server has to be powered down or renamed).
For rollback one generally has as thorough acceptance testing as possible - if that fails just power down the new server and power up the old one. Once clients are connecting and adding new data you have gone past the point of no return & know you have to fix any problems that occur on the new server.