It almost sounds as though you have an ulterior motive here; are you sure you're not just using this as an excuse to allow circumvention of the version reply? It should be fairly obvious that mIRC doesn't ALWAYS display the version, as this would make any client vulnerable to DOS attacks-- forget some new and obscure SSL attack vector.
Also note that VERSION isn't even the only problem here-- CTCP PING allows for arbitrary responses by filling the timestamp parameter with a constant value that is returned by the client. Many clients follow this protocol (all of them do, AFAIK), so this makes pretty much any client vulnerable to BEAST attacks-- mIRC is hardly alone here. You would, of course, plug this hole the same way you would plug the VERSION vector, and the same way in any client, by ignoring CTCPs.
It is clearly possible to ignore CTCPs, and, if you were being flooded with hundreds of requests, Flood control (if enabled through Alt+O -> Flood), or any flood script, should have already kicked in.
I don't think the version reply behaviour needs to change in order to patch this issue. That would be the backhanded way to solve a problem that has nothing to do with CTCP. Upgrading protocols to TLS 1.2 is likely to come soon because of this vulnerability, both from servers and mIRC-- it might take a little longer, but there are also other SSL related fixes that can be applied at the source of the problem.
