I am not sure if you are proposing an in-place or migration upgrade. As this answer indicates, I prefer migration upgrades when possible.
Assuming a migration - you shouldn't need to rely on any SQL Server 2012 features to assist in the migration and reduce the downtime. For your new environment planning, you might look into AlwaysOn Availability Groups and some of the benefits and differences from using failover clustering instances. Failover Cluster Instances are still a fine option in SQL Server 2012, though. Especially when you want to use shared storage, keep a copy of the data, have the DBs, jobs, logins, etc. all just work the same on the passive node as the active node.
As to how to make the migration faster - I talk about it a bit in the linked answer above - but basically you could do a plan like this if migrating:
- Build the new environment and test it/prep it for readiness
- Do a test migration to it, verify apps look good and work. Hopefully you can freeze jobs and logins at this point so you have the jobs and logins you need moved over
- For the actual live cutover - restore full databases to it specifying with norecovery (this is assuming your DBs are already in full recovery mode on the source, if not they'll need to be properly there.) from your latest full backup.
- Using a combination of differential and transaction log backups, restore the backlog of diffs and transaction logs (again specifying with norecovery) until you get to
- When you are "caught up" on your restores and have your "cutover window" - you can hold activity, do your last log restores - finally specifying with recovery on the last ones and ensure all apps are good.
That is an approach to minimize the downtime when doing a migration style. When you do an in-place it's a different story and there frankly isn't a whole heck of a lot to be done to change or speed up processing.
Obviously this is a decision you would have to have made well ahead of the upgrade - in place doesn't need new hardware.. Migration does.