MIDI status bytes

Sounds like a PIC 18F2550 is just the thing, or maybe a 18F4550 if the extra I/O lines are needed. I don't know why you say a PIC 18 is not easy. You say you are a programmer, so I don't see what you're afraid of. Perhaps nobody has done a MIDI USB interface ready for you to add the keyboard scanning code to, but certainly there are various examples of the basic USB driver out there. Microchip has some code, and so do I. My 18F USB firmware is available from the downloads page, and fits into our PIC development environment.

I've never done a MIDI device, but I sortof vaguely remember there is a USB class standard for that. If so, then it's really easy since you don't have to write a host driver and it will work with any OS that implements that USB class. All you have to do is look at the class definition, fill in the right enumeration data in the include file for that purpose, then send/receive data over the appropriate endpoints according to the standard.

Any other microcontroller will require something similar. Again, short of finding free USB MIDI firmware out there (which you say you can't find), you need to do pretty much what I said above regardless of what flavor microcontroller you use. USB is USB, so all the USB device peripherals in microcontrollers do pretty much the same thing with only a few details different.

Interrupts are your friend for timing sensitive tasks, but only if you put the timing critical aspects into the interrupt, and there are no other interrupts happening that have a higher priority. The microcontrollers on the "AVR-based" Arduino (e.g. the ATmega328P) have fixed interrupt priorities as detailed on page 58ff of the datasheet. So if you used TIMER2 COMPA as your critical timing interrupt and no other interrupts you should be OK (as it has the highest priority). If you also want to use lower priority interrupts, you need to make sure that all of them re-enable global interrupts when entering their interrupt service routine:

When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts are disabled. The user software can write logic one to the I-bit to enable nested interrupts. All enabled interrupts can then interrupt the current interrupt routine.

(p. 14 of the datasheet)

This is slightly different on ARM based Arduinos as their Cortex-M3 core has a "Nested Vector Interrupt Controller", where the priorities aren't fixed (can be set in software), and nested interrupt handling is the norm. So for timing critical applications, the ARM based Arduino would give you more flexibility. However, I don't think that's really necessary for your application.

The bigger question is really how easy these things can be implemented with the Arduino libraries. To get the best performance you will probably have to code outside the libraries to some degree, at least for the timing critical bits, i.e. avoid things like delay() or millis() altogether.

Whether or not you need to split depends on how much processing you intend to do. Again, going outside the libraries can potentially give you better performance.