Don't cross-post!

Try a Google search with "twitter arduino enc28j60".

I'll convert the flow to onRequest, instead of onReceive, and poll Slave 1 from the Master. Did I get that correct?

Not really. The usual way to use I2C communication is to have a register based device. To control the device you write to some registers or read from them. To set a register you first send the register address and then the value. Reading is similar. You first write the register address. When you start reading the device will start at the last register address you wrote.

To get your communication between the Arduinos up you have to define your set of registers and what they are good for. Then implement the slave that way to act like a chip device, so when the master writes some register it does one thing, when the master writes to the second register it does another thing. The master can also read the value of some register to get resulting or sensed values back from the slave. This is a completely different way of talking to the slaves than you would with a two way serial connection.

Please help me understand why they work in one instance and not the other.

If a write the serial interface succeeds within an interrupt handler depends on several factors. The problem is, it's executed while another part of your program is interrupted. The buffer of the serial interface is filled up with new characters. If the buffer fills up to it's upper limit, the call blocks till the buffer gets emptied. If the call was made within an interrupt, other interrupts are disabled, so the buffer will never be processed.

You have to take care for the variables too. Every variable you use inside an interrupt handler and in your normal code has to be declared "volatile", else the compiler may optimize it away.

Also, do calls to different slave devices take any processing cycles away from the non-called slaves?

No, the hardware will take care for that, the MCU knows the address and will call the interrupt routine only if it's been addressed accordingly.

I'm having a difficult time understanding the distinctions when it's truly needed.

In most situations they are not needed. If the datasheet of a device specifies that the MCU has to wait some time before putting some other line HIGH or LOW, you may have to insert some delays but in almost all cases I know, these delays are not calls to delay() but to delayMicroseconds().
The delay() call is handy if you want or have to wait some time and you know that the MCU doesn't have any other task to do. Many people are lazy and just insert some delay() calls although they don't know why they're doing so. Often they tried and with some delay it worked for them, later some other people use the same sketch with minimally different circumstances and the code will fail. You should always take the correct way (perhaps wait for some pin to become HIGH or for a value to appear in some register, etc.).

but am still not sure on its compatability with the Mega

At the web page they explicitly note the compatibility with the Mega. It communicates by an UART (serial RS232-like interface) so you shouldn't have any problems with the Mega.

As for the display: there are masses of displays available ready to be connected to the Arduino platform. You have to specify what you need (how many characters, what size, color, etc.). The cheapest (and well supported) LCDs are the 16x2 character displays with a parallel (4-/8-bit) interface and HD44780 controller.

The twitter library from the playground (http://www.arduino.cc/playground/Code/TwitterLibrary) does not work with an ENC28j60 based shield but only with an Arduino Ethernet Shield or compatible (WizNet5100 chip).

Maybe something like this will serve you?

http://www.seeedstudio.com/depot/water-level-switch-p-565.html?cPath=156_160

Which is the "other" board?

Both of them don't have HTTP overhead, they communicate on the TCP socket layer. Just because an example is often made with the most commonly used protocol on the internet it doesn't have to mean that you cannot do any other protocol.

Code:

void receiveEvent(int numBytes) {  Serial.println(".receive.");
}

This is called in interrupt context, you cannot put something out to the serial interface (the serial interface uses interrupts too which are blocked during the interrupt handler).

Code:

    SlaveIn.begin(details(Srxdata), &Wire);    // start ET library, pass data details and serial port.
    delay(100);
    SlaveOut.begin(details(Stxdata), &Wire);
    delay(100);
   
    BatManIn.begin(details(BMrxdata), &Wire);    // start ET library, pass data details and serial port.
    delay(100);
    BatManOut.begin(details(BMtxdata), &Wire);
    delay(100);

The I2C bus is not a full duplex bus as the standard (USART) serial interface is. The communication is always controlled by the bus master. Although theoretically there can be multiple bus masters this feature is not supported by the Wire library and you shouldn't use it anyway under normal circumstances.

The bus master initiates a communication by addressing the slave, tell it if it's a read or write request and then supplying the clock signal for both the read (data line is handled by the slave) and write (data line is handled by the master) transfers. So if you wanna receive something from the slave on the master, the master has to poll the slave periodically. And such transfers usually are following this scheme: the master writes the register address to the slave and initiates a read transfer from it. The slave sends the contents of the addressed register and any following if the master is still reading.

The slave is not able to initiate a transfer, it always has to wait for the master to initiate a transfer in either direction.

Why do you have the delays in here? They are completely unnecessary.

The web client example should be illustrative enough to show you how any client can be implemented. There are other examples in the appropriate directory in the library distribution. Probably SimpleClient is better suited for your needs.

I have only connected Tx and Rx pin to Arduino pin 2 and 3 respectively. and Vin from arduino to 3.3v and Gnd to Gnd.

Do you really have a WiFly shield (with the RN-131C)? These use an SPI2UART chip and don't have RX/TX pins. The software is also communicating over the SPI bus and not the USART of the Arduino.

is this true or did I overlook something in the software?

Yes, this is true, for the current version of the firmware (and libarary) there's not possibility to set the IP from the Arduino.

is it true that this shield can only be used for
webserver applications?

No, here's an example application
http://asynclabs.com/wiki/index.php?title=WebClient_sketch

Or can this shield also be used with the 'original'
library software?

No, it can't. The Asynclabs WiShield uses the Arduino process the TCP/IP stack where the Arduino Wifi Shield has it's own processor for that.

You don't have to copy Arduino.h, just include it.

I think that my arduinos have a crystal oscillator: I have a Mega 1280 and a Mega 2560.

At least the Mega2560 has a ceramic resonator too, the Mega1280 seems to have a crystal (on the pictures, I don't have one).

What kind of device is your device 2?

Please use the code tags (# button in the form) for all code, else there are problems for us reading it.

Do you have the possibility to change the GSM provider? Maybe you can call their service center and they disable the proxy for your account? What country are you in? What provider do you use?