Many read and writes will be in time, so, no wait will be necessary.
The real problem is only with the reads. When you do a read request, occasionally, if the ram controller just sent a refresh command, your read can take as long as 360ns+150ns+? when using the largest 8gb DDR3 ram chips, or 90ns+150ns+? for a 512mb DDR3 ram chips with the Z80's read channel priority set to max, or above all other channels (recommended). At max priority, the reads will typically take 100ns to 150ns unless the read is a cache hit where the read will only take around 20ns or if the read is within the same activated page where the read will take around 50ns. Since there is a nasty extended penalty when using the 'wait', you need to find out when is the latest you can issue a wait so that if a read can makes it back in time, you will not need to pulse the 'wait' line to the Z80. It's also not that the ram want have your data within 750ns, it's that you really cant release the wait until the ram has delivered the read data, as in you cannot predict in advance and disable the wait early before the read acknowledge has come in.
Since the you will have a 2 word write cache and the Z80 is so slow, I doubt you will ever need a wait state during a write, however, for the writes, you will know in advance if that cache is full when you receive a write command. It is also easy enough to increase the write cache size by a byte or 2 meaning the Z80 will not be able to out-pace the DDR3 no matter what the DDR3 may be doing elsewhere.
(Yes, smaller DDR3 ram chips refresh much faster than the larger ones. Here is your selection:)
// 512mb, 1gb, 2gb, 4gb, 8gb **** Refresh time for each size of DDR3 Ram.
localparam int ttRFC [0:8] = '{90000, 110000, 160000, 260000, 260000, 360000, 360000, 360000, 360000}; // minimum time in picoseconds
The DECA board right now has the 4gb chip, or 260ns.