There's two parts to this question:
First, can you use the Failover Partner connection string tip with AlwaysOn Availability Groups? No. AlwaysOn AG's "Listener" technology is the replacement. Have your connection strings point to the listener name and they'll always get the primary replica. (For the next part of this answer, I'm assuming you're using the listener name - if you're not, start, heh.)
Second, why do some queries fail to connect to the listener? This has to do with the number of DNS entries for the listener. All possible subnets for the listener will be in DNS at all times. If you've got a listener in 192.168.1.X and another in 192.168.100.x, both listeners will always be in DNS. By default, your clients will try connecting to each of the DNS entries serially, and not always in numeric order. If you've got a 30-second connection timeout, it's possible that your app will only try one of the IPs and then fail before it has the time to try the second one.
If you want to try connecting to all possible IPs simultaneously, check out the MultiSubnetFailover = True options for the SQL Server client as described here: http://msdn.microsoft.com/en-us/library/hh205662.aspx
Otherwise, you'll need to increase your connection timeout to account for the multiple IPs.
Update Feb 27: the question added, "I was therefore trying to come up with a way to avoid manual intervention for these (replicated) DBs should a failure of the replica occur and the other databases which are part of an AG failover."
Ooo, unfortunately, no, if the databases aren't part of the Availability Group, you're going to be doing manual work in order to fail over. One popular option is to use a DNS record, and just repoint the DNS record at whatever server is currently hosting the primary copy of the databases.
When a Secondary (Node 3) is running in Asynchronous-Commit mode, Primary (Node 1) does not wait for a confirmation that Secondary has indeed finished writing the logs to its own log file.
It will still wait for a confirmation from a secondary in Synchronous-Commit mode (Node 2) though.
Right after Node 1 will be finished writing the log record to its own log file, it will consider that the transaction has been completed and the client will be notified.
With Asynchronous-Commit mode, Secondary is considered to never be synchronized with the Primary.
Secondary always remains unsynchronized and some lag with the Primary is to be expected although it will try to keep up and catch up with the Primary,
Therefore problems or lags on a Secondary in Asynchronous-Commit mode won't impact the Primary.
Much more information are available on this MSDN page: Availability Modes (AlwaysOn Availability Groups)
Best Answer
No, there's no way to do zero-downtime failover with AlwaysOn (or in SQL Server in general, as far as I'm aware). To do that, the SQL Server you're connected to would have to do state transfer to another node mid-query, and since many failovers are unexpected, that's not possible.
However, you can enable "read-only secondaries" in AlwaysOn, and then your readers would have zero-downtime when the primary server fails over - since they're connecting to a secondary copy anyways to do their SELECT queries, they wouldn't even notice the failover. There would still be an interruption for users with a "Write" connection open, but at least some part of your user base would be uninterrupted.