There are a bunch of things in FastLED that are designed with portability and abstraction in mind - https://github.com/FastLED/FastLED/blob/master/PORTING.md has some beginning notes (the most important thing that needs to be done is pin access needs to be implemented - once you have that, then SPI output can be bitbanged (until you implement hardware SPI support)).
So far, I’ve ported FastLED’s deep internals to the AVR architecture, multiple ARM architectures (from freescale, stm, nordic, nxp), the xtensa architecture (the esp8266, and soon esp32).
Most of FastLED doesn’t rely on anything from the arduino infrastructure (I have some code that falls back to using arduino methods for pin access - and right now FastLED uses the arduino methods millis, micros, delay, and a handful of others - though that’s all easily swapped out over time).
Some tricks/problems with this platform.
Like the PIC, the 80C52 takes multiple clock cycles for 1 machine cycle. 12 in normal mode, 6 in X2 mode. That caps your instruction cycle rate at about 5Mhz compared to the AVR 16Mhz rate - also, far more of the 80C52 instructions take 2-4 cycles than AVR (where most instructions take a single cycle).
You only have 8 registers compared to AVR’s 32, but you’re even more constrained, because all math operations require working with the Accumulator register - which adds extra cycles of moving things in/out of the accumulator.
So, it will take you more instructions to do an equivalent amount of work on the 80C52 as on the AVR, and those individual opcodes may take longer than their AVR counterparts, and you only have 1/3rd the number of instruction cycles per second to play with.
For the most part, this shouldn’t be much of a problem. It just means that most code will run slower than the equivalent code. That’s ok - there’s a version (greatly restricted subset, of course) of FastLED that runs on an Apple II’s 6502 CPU 
(Hi, @Mark_Kriegsman !).
If, however, you want to use WS2812 leds (neopixels) - then things start to get ugly. You have exactly 1.25µs to write a single bit out. I had to do some fairly heroic asm gymnastics to make this work on an 8Mhz AVR with no hardware multiply (while keeping the inline dithering/scaling) - there there are only 10 CPU cycles per bit, total. On that atmel chip, however, there’s only 6.25 cycles per bit (let’s call it 7). There are games that I’ve seen people play with abusing UART outputs to sort of drive WS2812 leds, which may be what you’d have to do - but even then, you’d still only have 7 cycles to prepare each byte to be written to the UART (because this hack uses two 8-bit values, one representing a 0 bit and one representing a 1-bit).
Anyway - not saying it’s impossible - it’s quite possible, especially if you stick with 4-wire led chipsets like the APA102 (which use a clock and data line, and can be much freer with their timing) - but know what you’re getting into