Experimentally wrap tinfoil round the cable, and earth it at the driving end. Or the chassis, but not both. If that works, you can find a better way of screening the cable.
Or a series termination at the driving end of the clock signal; this will somewhat slow up the clock edges; in other words reduce the harmonic content.
I have my doubts about this : if the clock is 30MHz and the peak is at 60MHz that's only the second harmonic. Which means either : the clock is a LONG way from being a square wave (duty cycle is far from 50%) or: the EMI is from other sources (perhaps the RGB data : does the emission go away with the screen black?) Some further information from these experiments and questions may help.
EDIT: If you can scrape up a spare wire in the connector, add a differential driver for the clock at the driving end (the LCD controller) and transmit the clock and its complement down adjacent wires. At the receiving end (the LCD) use a differential receiver to regenerate the clock. This has two advantages : first, the clock waveform will be more accurately preserved despite the cables and EMC filters, and second, the radiation from the two clock lines will cancel each other out, reducing your EMC emissions.
Electrically it is possible, the only thing you'll need to do is level-shifting from 1V8 to 3V3 since most of the displays use that voltage; the problem is that you won't have the image from the OS framebuffer appearing on the display, unless you find a display driver that does that (which AFAIK doesn't exist). Even if you find such driver, its refresh rate would be so slow that it wouldn't be useful for most typical uses (command line and GUI), not to mention it'd hog the processor to do that. But you could write a small program to transfer the framebuffer to the display when you want, or generate the images you want to show directly in the display from your program.
The capes use the DSS pins, which doesn't require work from the processor to periodically transfer the framebuffer to the display and is natively supported by the OS; also the fact that it uses parallel lines for each color bit and is intended to be wired with short length connections result in a throughput much higher than SPI can handle. To better understand the DSS interface, check out this material (it's for VGA, but the concepts are the same).
If you want to connect via DSS, you'll need to level-shift the VSYNC, HSYNC, DOTCLOCK and ENABLE pins, the 24 color pins, (R0-7, G0-7, B-07); those will be connected to the corresponding pins at the BeagleBone. And the CS, SDI, SDO and SCL pins for initialization; those would be connected to CS, MOSI, MISO and CLK of an SPI port. To initialize the display you'll have to output the init sequence that the display manufacturer dictates (you'll have to look at their website or ask them for it). You'll also need to read the display spec for other requirements and mode programming pins, and for instructions on how to drive the backlight.
For the touchscreen, notice that the display you mentioned doesn't have one, but there's a version with touchscreen for the same product. You'll need either that or to buy a separated touchscreen. To interface with it you'll need two ADC lines and an IRQ line, check out this reference.
Best Answer
The EPSON datasheet has an incorrect formula for calculating the value of the horizontal display width register (HDISP [16h]). The formula should read:
HDISP in number of pixels = ((REG[16h] bits 6-0)) x 8
Instead of:
HDISP in number of pixels = ((REG[16h] bits 6-0)+1) x 8