You can account for the jitter with set_clock_uncertainty if the Cyclone II handbook has a separate spec for output jitter when using an I/O pin. If it's not in the handbook, you'd have to guess how much clock uncertainty to add. I was probably looking at Cyclone III when I saw a separate spec in a handbook. If the Cyclone II handbook doesn't have the separate jitter specs, you could use the difference in jitters in the Cyclone III handbook for a rough guess for the Cyclone II difference. In Cyclone II, the guard bands in the timing model might be enough to cover the jitter for a dedicated clock output with no set_clock_uncertainty, but don't assume the guard bands cover the additional jitter for an I/O output.
As Jake said, Quartus accounts for the skew automatically, but you do have control over how much the skew is. Driving a clock output from a PLL to an I/O pin directly probably has more skew relative to the data outputs than you would have if you drove both clock and data outputs with I/O cell registers configured the same way. The PLL output would clock the I/O cell DDIO registers that have their data inputs hard wired to high and low. You use the same PLL output for data and clock registers if you don't need a phase shift and a separate PLL output for the clock registers if you do need a phase shift.