No it doesn't work like that. I was a coder for years and I know what I'm talking about.
The hardware always runs at the same speed regardless of region, all that changes is the period between vertical synchronization pulses. 50hz gives 20ms between vsyncs, 60 gives 16.6ms. That's the window (or multiple thereof) you have to get the work done, and its obviously bigger when there's more time between frames.
Generally speaking the biggest issue was that if you had a static asset, like a static bitmapped image for a splash screen, that would have to fit both frame sizes. The choice being to either crop it when going from PAL to NTSC, or simply use the smaller (less memory) image for both and leave black space on lower/upper edges on the PAL build letterbox-style.
In the case of vector assets/rasterized imagery, then you could simply stretch it, safe in the knowlege that although the AR was somewhat fudged it would simply render as normal.
Where things got sticky with NTSC to PAL conversions gameplay-wise was when events were specifically timed with delays defined by n-number of frames, like moves within fighting games. Because obviously the game was tuned for a certain "feel" with a specific base time-unit in mind, and re-timing everything (including animation frames) to match, would be a huge job. In such instances, offering PAL60 output was the correct solution.