You've correctly identified the main factors limiting LS bandwidth:
Maximum Interrupt Poll Rate: $\mathbf{10 \text{ ms (100 Hz)}}$. This is the major bottleneck. This rate is mandated by the USB specification for LS devices.
Maximum Packet Size: $\mathbf{8 \text{ bytes}}$. Also a strict specification for LS (Control and Interrupt endpoints).
Your calculation is spot-on: $100 \text{ packets/sec} \times 8 \text{ bytes/packet} = 800 \text{ bytes/sec}$. You need $\approx 10 \text{ kbytes/sec}$.
Given that you control both ends and compatibility is not an issue, here's an assessment of your options:
Feasibility: Technically possible, but requires significant effort and deviation from the spec.
Mechanism: The Host Controller (i.MX RT1060) determines the polling rate.
On the Host (iMX RT1060): You would need to modify the Host Controller Driver (HCD), specifically the part that manages the Scheduling Table or Frame List. For a full-speed/high-speed controller, the frame interval is 1ms (1000 $\mu\text{s}$). For LS interrupts, the standard dictates they can only be scheduled at intervals of $2^{\text{N}}$ milliseconds, where $N \ge 3$, which means $8 \text{ms}$ or $16 \text{ms}$ (10ms is a common approximation or implementation maximum). You would need to force the HCD to schedule the LS interrupt transfer in every $1 \text{ms}$ frame.
Result: If successful, you could achieve a $1 \text{ms}$ polling rate ($\mathbf{1000 \text{ Hz}}$).
New Bandwidth: $1000 \text{ packets/sec} \times 8 \text{ bytes/packet} = 8 \text{ kbytes/sec}$. This gets you very close to your target!
Feasibility: Not possible.
Mechanism: The maximum packet size for LS Interrupt and Control endpoints is hard-coded into the USB Protocol itself and the hardware of the transceivers and host controllers. This is not a parameter you can change in the driver. The Host Controller (iMX RT1060) is designed to only accept 8-byte packets from an LS device's interrupt endpoint.
Feasibility: Low utility for this specific problem.
Mechanism: You would use the standard HID class (which is available on LS) or define a Vendor-Specific Class (VSC).
Impact: A custom class simply allows you to define your own Report/Transfer structure, but it does not override the underlying protocol limitations of the LS bus, specifically the $8 \text{ byte}$ packet size and the $10 \text{ ms}$ polling interval.
The most promising path is to modify the Host Controller Driver (HCD) on the iMX RT1060 to force a $1 \text{ms}$ polling rate for the LS interrupt endpoint.
Understand the HCD: Identify the specific Host Controller hardware (likely a Synopsys or similar core within the iMX RT1060) and locate the relevant driver code (e.g., Linux's $\text{OHCI/EHCI/xHCI}$ or the bare-metal equivalent provided by NXP).
Inspect the Schedule: The HCD maintains a Frame List or Schedule for every $1 \text{ms}$ frame. It determines which transfers happen when. LS and FS transfers are scheduled in the same $1 \text{ms}$ frame, but LS transfers must respect the $10 \text{ms}$ rule.
Bypass the Check: You need to find where the driver enforces the minimum $10 \text{ms}$ interval for LS interrupt transfers and override that check to allow scheduling in every $1 \text{ms}$ frame slot.
Packet Chaining: On the Device side (LPC55S69), ensure your firmware is ready to service the endpoint immediately with new data. Since you're polling faster than the spec, you'll need to chain multiple 8-byte packets together as quickly as possible. When the host requests a packet, the device should quickly respond with the next 8-byte chunk of data.
Crucial Warning: Forcing a $1 \text{ms}$ poll rate on an LS device increases the Bus Utilization significantly, potentially violating the $90\%$ max utilization rule and possibly causing timing issues or errors. You must thoroughly test for NAKs, CRC errors, and unexpected disconnects.
No, it is not a lost cause.
You are aiming for $10 \text{ kbytes/sec}$.
The theoretical maximum LS bandwidth is $\approx 150 \text{ kbytes/sec}$ (not counting overhead), so the signaling rate can support your traffic.
By pushing the poll rate from $10 \text{ms}$ to $\mathbf{1 \text{ms}}$, you get $8 \text{ kbytes/sec}$, which is very close to your target and likely sufficient with some minor protocol optimizations.
Recommendation: Invest the time in modifying the Host Controller Driver on the iMX RT1060. This is the only change that directly addresses the major bandwidth bottleneck (the polling rate) and offers the most significant payoff.