I think this is a pretty bad idea - you would need to create a centralised service which somehow knew all the version details of all your service endpoints, and then require your consumers to make an extra call in order to consume your services.
This creates a single point of failure in that if the "Version Checker" service is unavailable then "valid" consumers (ones with the correct client version) will still be unable to call your services.
Also you would need to maintain the current version of each of your services in this central location, which generates support overhead.
The best way of versionning your services is to try to make non-breaking changes so that older versions of the clients can be supported. You an do this in many ways. I have posted about this before here and here.
If you must make breaking changes then you either need to let your consumers break (and therefore be forced to upgrade) or you co-host different versions of your services at different endpoints.
NOTE: There is something which is kind of designed for what you are thinking of, called UDDI. The idea behind a UDDI server is it can store all the information about your services, including endpoint address, transport and even your exposed types, so that consumers can query the UDDI at runtime and assemble a client on-the-fly.
This would result that your consumers need to have absolutely no knowledge of your service version at all, and would retrieve this information at runtime from UDDI.
However UDDI is rarely used (probably for the same reason that it introduces a single point of failure). I have used it exactly once in my career when I built an ESB for a client.
EDIT
In response to your comment, I think the best solution for you would be to expose a Version member on your service operation request contract type which would require consumers to declare which version of the service they are expecting to call.
When the request is received, you can interrogate the request and check the version. If they don't match then you can throw an exception of a type you have defined in a FaultContract. (more about fault contracts here).
This will enable your consumers to wrap the service operation call in a catch block and handle the custom exception type passed back. I don't think there are any built in exceptions which cover "invalid version" errors so you will need to define your own.
This means that consumers will only get an exception back when they try to call your service with an outdated version attribute and avoids having to make an extra service call. Also it distributes this information rather than centralising it (which is more robust approach).
EDIT 2
In response to your comments, Fault contracts are not supported in asmx. You will have to throw the exception on the service and then on the client catch the exception as a SoapException. On the client you then have to interrogate the SoapException message (not nice) in order to work out if it's because of versionning.
