You cannot introduce delays in a generic way without (potentially) breaking functionality, because some / most of scanning is subject to timeouts. When a tool wants to know if port X is open on host Y, it sends a packet which targets that port; if it does not receive a response within a given time T, then it decides that the port is "closed". The timeout period starts as soon as the tool believes the packet to be sent; if you delay the outgoing packet from the outside, then the tool will believe that the port is closed while its packet has actually not been sent yet.
If you really want to delay packet sending from the outside, then you will need heavy tools. You could imagine running the tool within a modified QEMU virtual machine, with opcode-by-opcode emulation; the modification would be about "stalling" the VM regularly, i.e. letting it run for only ten thousand cycles, then block it for two seconds. What the operating system inside the VM thinks of as the "real-time clock" would also have to be stalled, so that the VM does not notice the passing of time during its frozen intervals. There is no conceptual impossibility in this plan, but it would probably imply some rather tricky and convoluted programming (VM and emulators are not the simplest kind of code).
Alternatively, play with
LD_PRELOAD and/or ptrace (I am assuming a Unix-like machine) to intercept the system calls which do the actual sending of packets, and add delays at that point. IF the tool starts its timer immediately after the system call, then this will be sufficient; if it starts the timer immediately before the system call, then you will have to alter the process' notion of current time, i.e. intercept
gettimeofday() as well (and, on modern Linux systems, this can be a bit harder because
gettimeofday() does not necessarily involve a "true" system call).
If the tool manages several packets in parallel (it launches a full batch, then waits for all possible responses simultaneously), then these delay-based methods will not work (not satisfactorily, or at all).