The simplest seeming answer would often be to use 'Set Attribute.vi' to change the counter's output polarity. Then the counter will be at a high state during the delay and low during the pulse. However, that would also put it in the high state while armed and waiting for the trigger, and again after the pulse completes. It doesn't seem like that would work for you.
A near-miss idea would be to leave the polarity alone and simply specify the shortest possible delay. Use the internal max timebase as a source and set "Pulse Spec 1" == 2. On a 660x device, that'll only delay you by 25 nsec.
In fact, you may be able to change that near-miss into a perfect hit. The short delay may or may not change the timing of the DMA transfers relative to the trigger, depending on exactly how the "generate pulse train while gate is high" function is implemented. Here are some ways I can imagine:
A. The "pulse while gate is high" counter is always cycling internally. An output signal is always being generated on the TIO chip and is always being AND'ed with the state of the Gate signal coming in. The result of the AND is sent to the actual IO pin.
B. Similar to (A), but the AND'ing is done only when there's a state transition and the result is latched until the next state transition.
C. Internally, the pulse train counter always *wants* to run, but its Source is always being AND'ed with the Gate signal. Then, as far as the pulse train counter is concerned, time is frozen when the Gate is in the inactive state. This is how I *think* I remember it working.
In cases (A) and (B), the timing of the DMA transfers wouldn't be affected except for the rare case where the trigger event occurred within 25 nsec of a "scheduled" transfer. In case (C), you can compensate by changing the duty cycle of the "pulse while Gate is high" counter. Simply subtract 2 from "Pulse Spec 1" and add 2 to "Pulse Spec 2". Then (assuming its polarity is low state delay, high state pulse) make sure the encoder counter Gate is set to do DMA transfers on the low-->high transition.
Final note: if timing synchronization between analog and encoder is really important, there may be a better way. As I recall, the AI start signal does not have deterministic timing relative to the actual A/D conversions. You might instead have two counters of the 660x set to "pulse while Gate is high" and set up the other one to be the AI scan clock. Then you'd be more fully in control of their time==0 marks.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.