You can't get a high ID using a SOCKS 5 proxy. The BIND command in a SOCKS 5 proxy is not meant to do that.
Consider the problem of two clients that want to bind to the same port. How is this solved? "Hey, the first one to ask, gets it right?" Sure, that was my first idea. But that is not how it works. Binding with a proxy is something contradictory in principle. Why would you have gone to the trouble of setting up a firewall if you will allow external client to bind? That would be just network overhead.
BIND in SOCKS 5 asks the SOCKS 5 server to bind to some port. The port to which it actually binds is returned to the SOCKS 5 client. The SOCKS 5 client can make no assumption on which port will be actually bound. The SOCKS 5 client must then return this information to the other application so that it may now attempt a connection to the newly bound port. Seems useless at first, but ftp does make use of it.
A server application inside a firewall, in order to bind to the external world, would have to extend this protocol to ask for a particular port to bind, which is not possible as of RFC1928 - SOCKS Protocol Version 5. There should be some error handling also for already bound addresses. But hey, again, why were we using a firewall in principle?
Don't get me wrong, I am not playing dumb here, just trying to clarify an old issue. What was originally expected was a proxy that could allow you to bind through a firewall, which is indeed possible, but not with the current SOCKS definitions.
On the other hand, aMule does support the UDP_ASSOCIATE command, what means that if you use KAD, you should get the same results either with or without a proxy. I just don't know how would a public SOCKS 5 server behave with such an UDP traffic, it would probably fail miserably, and indeed, most public SOCKS 5 servers I have tested when I implemented SOCKS 5 in aMule were UDP disabled.