How a modchip overrides specific signals?
That's the part that is clever about modchips - they generally use one or a combination of several techniques to achieve their intended function without ever needing to attempt to override a CMOS logic signal.  For exactly the reasons you mention in your question.  

If it were as simple/easy as simply overriding CMOS lines, then it would be totally trivial to create a modchip.  You simply soak up the highs and force lows when you want, and put anything you desire on whatever pins or bus at will.  Unfortunately, most CMOS outputs have either a 50Ω or 25Ω 'on' resistance, either to VCC as well as GND, or just to GND (depending on if it is an open drain or push-pull output or not).  The PIC and AVR microcontrollers, for example, have 25Ω push pull outputs.  In the PICs case, they are really only rated for a maximum of ±25mA sink or source on any pin, and likely have similar resistance as to other CMOS output pins, overriding one of the lines would require paralleling several pins together.  All of these are faults that most CMOS chips might tolerate if the condition is brief enough, but there is no expectation of the chip surviving something like that if it occurs over and over.  If you exceed the absolute maximum ratings, then you've entered territory where the chip may in fact be incurring damage.  Even if it works once, or works a few times, it could be slowly destroying some oxide layer or causing hot carrier injection or a multitude of other wear mechanisms that will eventually result in the failure of that IO pin.  

So, as Boromir might say, "one does not simply override CMOS signals."  

The strategies used are usually extremely specific to how copy protection (or whatever) functions, and it can often take hackers a lot of time before a weakness is found that can be exploited that works without overriding logic signals.  

Let's talk about the PS1 modchips.  The PS1 copy protection worked by trying to read a short, 4 character string from the inner most section on a CD embedded in the wobble groove, known as a wobble code or simply wobble groove data.  This is basically tracking information - it is what lets a CD read head know where it is on the disc, maintain a constant angular velocity, that kind of thing.  On a music CD, the wobble groove data is usually read on a sub channel, and will contain the time position for that area on the CD.  This is where the HH:MM:SS time is generated on a CD player - by actually reading it from the CD.   

The important point about wobble groove data is that this wasn't something that could be 'burned' to a disc - it was embedded in the physical structure of the CD itself.  Indeed, it must already be present to even burn a CD, and when you buy CD-Rs, they are discs that have pre-made wobble groove data already there so your CD burner knows where to actually put the pits on the disc when you burn it.  In other words, it had to be pressed at the actual factory producing the physical CDs.  

Seems like a pretty fool-proof means of copy protection, right?  Well, there was one critical weakness, and that was the simplicity of the protection at every stage further along than actually reading the physical media.  

There were a few different strings the copy protection looked for in this wobble groove data, and they corresponded to different regions, allowing both copy and region protection in one mechanism.  The string was 'SCEA' for Region 1 (SCEA simply being an initialism for Sony Computer Entertainment America).  There were others, like SCEE (same but for Europe), but as long as the drive controller found that string, the PS1 would proceed to boot the disk.

The wobble groove data is streamed as a serial bit stream as a disc is read.  It is much lower density than the actual recorded data on the disk, and in the PS1's case, it was a 250bps serial stream.  Quite slow, slower than even a 300 baud modem.  

More importantly, it has its own dedicated sub channel, which means it will have its own bus and set of digital logic lines in the actual hardware.  This was a very typical and standard setup used with (and for the most part, still is I believe) optical disc drives.  It is analogous to the tracking data on a VHS tape.  

So the main PS1 CPU received this bitstream from the disc drive controller on a specific sub channel - sub channel Q in this case - which has its own CLK and DATA line.  Conveniently, this was a bidirectional bus - the CPU also used those same CMOS lines to tell the drive chip what area of the disc to read the sub channel data from.  

So, how do you perform injection without having to override either of these chips?  

You cheat.  

The earliest modchips used a fairly bruteforce method.  They actually manipulated the transistor that controlled the laser directly.  This is not even a digital solution, it was operating on the one analog part of this whole thing.  

It would have a connection to a pin that signaled when the CD drive door had been closed, and would trigger on this signal.  Since any transistor is going to have some sort of series base resistor, this made it a very simple task to manipulate without causing any shorts or high currents.  

And, for safety reasons, there was a 'diode gating' transistor linked with the door sensor that would completely disable the CD controller's connection to the laser diodes, turning them off, ensuring that no one could accidentally be exposed to the laser while the door was open.  

So the mod chip leveraged this to turn off the laser diode when it normally should be on, causing the controller to read nothing from that inner track wobble data, and with no signal being amplified, the mod chip was free to manipulate the read head's photo transistor directly using a digital pin.  It would wiggle the actual CD ROM drive sensor in just the right way to read out the copy protection string.  And at that point, since you've injected this at essentially the actual physical analog end point of the entire signal chain, everything from that point on is totally normal and native.  Actual data is actually sent from the CD rom drive controller, and it is the right data for a real sony PS1 disc of the right region.   

Once this is done, the modchip simply re-enables the LED gate transistor and normal operation resumes like nothing even happened.  

This is just one way.  Another method PS1 mod chips used was purely digital, and simply exploited timings.  It would sniff that sub channel Q serial line I mentioned earlier, and a high impedance input pin can sniff a CMOS line without any real interference with its operation (at least, normally), so no worries there.  And given how slow sub channel q was, it was well within the capabilities of a simple 8MHz µC.   

It would wait for the CPU to request the copy protection data on sub channel Q, then wait a little bit and inject the correct bitstream as a fake reply back to the CPU on the sub channel q serial bus.  Sure, the CD Drive control chip was still there, but it was busy actually moving the read head into position, finding the right spot on the disk, letting error correction do its thing.  All of these tasks take an eternity in µC time.  Heck, they take a while in people time scales.  So these modchips would exploit timing to simply inject digital signals when they could be sure there they wouldn't NEED to override anything else.  

If you're curious, you can see exactly how both of these methods worked here (laser diode gating) and here (SUBQ injection).

Yet another method popular in a variety of modchips involves triggering a reset on some chip - usually the main CPU or some sort of controller chip, or both - and again, exploiting that in someway, either to act as an imposter of one chip while the other one is temporarily deactivated, or simply to exploit the timing in some way that that opens up.  It's a safe bet that you won't have to override anything on the RESET line of a chip, since nothing is going to be telling it to reset (normally).  

And I am sure there are dozens of other clever tricks as well.  And there will continue to be new ones conjured up by clever hackers.  Not in the name of piracy, but simply to see if they can - and to learn about how a device functions.  I think normally the people who figure it out are just having fun with a puzzle.  At least, that is why I would do it.