This method helped a ton - I'm no longer running into infinite loops by using a signal like that. However, I am running into another issue due to the way that the interrupts work. Since getting a stop signal indicating the end of a message does not cause an I2C interrupt, I'm having truoble dealing with detecting the end of a message. The amount of time that it could take to get the stop signal is much too long to sit around and wait for it. The way that Freescale's sample code deals with it is to have the main loop of the program doing nothing but constantly checking for the end of message condition.
Unfortunately, this is not a practical way to handle the issue in the real world, so I had to find another way to do it. My current solution is to use a PIT (programmable interrupt timer) to look for the condition. Basically, as soon as I start to receive a message, I start the timer up and have it check every 30 microseconds (a value I picked out of the air - to really meet the I2C spec it would need to be even more often than that). Once the condition has been detected (or once we start to send or receive another message, meaning that the previous message must be done) the message received gets passed on and the PIT gets turned off. This method works, but I'm not sure if this will put a major strain on the processor due to the large amount of time it will spend checking the bus. Does anyone have a more elegant solution to this issue?