The phasor in gen~ follows the convention of Max's phasor, in which phase is represented in the 0..1 range (rather than -pi..pi range typical of trigonometric oscillators.) In fact, phasor just delivers a simple ramp from 0 to 1, useful for LFOs, wave-table lookup, etc. As such, it's very easy to 'change' derive another out-of-phase phasor from the first by adding an offset and wrapping in 0..1 again:
[phasor] -> [+ phaseshift] -> [wrap 0 1]
Where phaseshift also ranges from 0..1. This is probably cheaper than using a delay. However, if you do want to use the delay technique, what you need to do is delay by some fraction of the phasor period (which is 1./frequency). So that might be something like this:
Note that I initialized the delay length as 'samplerate', which gives up to 1 second of delay. So this won't work if you drive it with frequencies below 1Hz.
In general, the offset & wrap technique is going to be cleaner and cheaper, but the delay technique has the advantage of working with any waveform.
If you want to dig into how phasor works a bit more, take a look at gen~.phasor in the examples folder; this shows what the phasor object is doing internally (more or less).
By default [wave] samples between start and end indices, a bit like the MSP [wave~] object. For what you're doing though, you could just use the [sample] object instead, which by default takes indices from 0..1. (Take a look at the 'buffer-and-data' tab of the gen~ help patch to see the differences between wave, sample, lookup, nearest, and peek.)
With that it's working for me here. The grainSize wants to be larger to hear the effect (delay times are measured in samples). You could save a bit of memory by using one delay object with 4 inputs (e.g. [delay 44100 4]), which gives several taps from a single delay line. But the rule usually is 1) make it work 2) make it right 3) make it fast (only if you need to)...