I very much share Nikolay's sentiment. You would most likely end up creating more issues for yourself than fixing (as this is not a trivial task as pointed out). Your proposed solution (Redis for HTML cache) for handling concurrency have several issues:
a) Clearing Redis cache will lock you entire cache, causing all servers to wait, unless u add some timeout and try to serve it either from a local file cache or bypass cache altogether.
b) A single cache controller server becomes a single point of failure.
c) For performance reasons - you may still want to cache Redis cache on CD's local file system. Not the entire, only per request, otherwise your severs will spend time to download the entire Redis cache to the local file storage during Sitecore warm-up.
d) You will need to handle concurrency of populating Redis cache during cache misses - this can become fairly expensive after any publish as Redis cache will be invalidated and thus every server serving request will be possibly subjected to cache miss (not different from today's situation, but it's just happening on a local storage, which is faster)
e) It's probably not as cost effective as using local storage.
There's a reason why HTML cache is local to the delivery server - moving it to Redis will certainly impact its performance.
If warming up your Sitecore instance, I'd rather suggest to look into your data caches - especially the prefetch - you may loading far too much than u need. The initial (by Sitecore) settings is very generic and you do need to optimize for sites with large content trees - you may want to tune it differently for CM and CDs. I'd suggest to check the rest of the caches to see, if you're not having too many misses due to the insufficient cache size.
You also mentioned hundreds of sublayouts - this should normally not be an issue as HTML cache is gradually populated, unlike prefetch cache. If this should be an issue than one could look at the performance of those.
To sum up, before venturing into implementing Redis for HTML cache (I'd leave that to Sitecore):
1) Optimize your Sitecore data caches (use Cache.aspx to check how they're performing)
2) Use ASP.NET and Sitecore counters to monitor performance of your CD, when booting up and once it's warmed up.
3) Check performance of your disk - Disk Queue Length - during CD boot up and and once it's warmed up. Maybe you need to switch to faster disks (SSD)?
4) Check performance of your code and pages using pipelines.aspx and stats.aspx
5) Consider using SDN, if you're able to cache so many sublayouts (depending on on the granularity of your HTML cache settings)
BTW: I believe Sitecore Data Caches are just local process caches, not ASP.NET cache backed up. That would make it more difficult to move out of process - again, the reason is speed.
Before reading my entire response - I suggest to have a look at the following threads, which refer to the same -