Doing the lights in the screen-quad pass is actually the whole point of deferred rendering, otherwise it's really just little more than a somewhat more complex forward renderer. The idea is that you move the more complex lighting equation to the screen-quad pass so that only pixels that actually appear on-screen need those complex equations. Of course, that assumes that your lighting is sufficiently complex to counterbalance the overhead of writing out your gbuffer; deferred isn't suitable for every lighting scenario, after all.
The trick is in knowing that you don't actually need to draw a fullscreen quad per-light. Instead you only draw the area of the screen that will actually be affected by the light, which - for most lights in your scene - will hopefully be rather small (otherwise with 60+ lights you're going to get quite an intense glare on everything).
There are a few ways of doing this, and I'm just going to mention one, which is to use a light volume; see e.g. here for one further explanation of this method. In short, you draw a bounding volume for each light with additive blending, and that gives you the desired end result. (Note that this method breaks if the viewpoint is inside the light volume, and one quick-n-dirty way of resolving this is to just draw a fullscreen quad for those lights. I'd use a simpler shape than a sphere too; an icosahedron is a decent fit.)
If you're not bothered about shadows you can make this faster by using instancing to draw all of your lights in a single call, which is quite efficient.
