Maybe you could artificially lag your own connection?  
High latency plays havoc on bandwidth usage, so maybe 
lagging the connection could help.  This would 
probably requiring using some FreeBSD QoS/AltQ 
packages.

Or finding a way to put a 'sleeper' into HTTrack's 
requests.  If you're into the commandline versions 
source code and know how to compile these things, try 
hacking the source to increase the delay.  Look near 
the max connections/sec code and do something simple 
to the logic that would let you be more granular.

Maybe change the multiplication code to be max 
connections/hour.

My impression is the detection script looks for 
continuous, non-bursty access to the site.  Bursty 
access (quick load of a single or a few HTML pages + 
their lages, long pause, quick load, long pause) is 
typical for human reading.  Slow continous loads are 
robotic.

Maybe you could do something with WinHTTrack's Mirror 
| Pause function to periodically pause the transfer 
manually, let it rest a bit, then resume later.  
Finding a way to automate the pause/resuming might be 
something to look into.