driving an ILI9341 display using SPI on the Bela Mini and using the GPU to draw?

Yes. On BelaMini, the pins I outlined above are for spidev 2.1, aka McSPI1, channel 1 (I know, it's confusing).

Note: the answer to this comes partially from this table which shows that P2.31 is the chip select for channel 1 (hence the .1). The reason why it's 2. (while the hardware is spi1) is that Linux seems to enumerate spidev devices starting from 1 instead of 0.

AliceBlackMage d, I hit a problem with the device tree overlay part though, as it wouldn't build the file they supplied separately to the driver

I copied the file NEOSEC-TINYLCD35-00A0.dts that they provide a download link for to the board, and successfully compiled it following the instructions provided: dtc -O dtb -o NEOSEC-TINYLCD35-00A0.dtbo -b 0 -@ NEOSEC-TINYLCD35-00A0.dts. What errors did you get?
The output I get is:

root@bela:~# dtc -O dtb -o NEOSEC-TINYLCD35-00A0.dtbo -b 0 -@ NEOSEC-TINYLCD35-00A0.dts
NEOSEC-TINYLCD35-00A0.dtbo: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
NEOSEC-TINYLCD35-00A0.dtbo: Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property
NEOSEC-TINYLCD35-00A0.dtbo: Warning (unit_address_vs_reg): Node /fragment@2 has a unit name, but no reg property
NEOSEC-TINYLCD35-00A0.dtbo: Warning (unit_address_vs_reg): Node /fragment@3 has a unit name, but no reg property
NEOSEC-TINYLCD35-00A0.dtbo: Warning (unit_address_vs_reg): Node /fragment@4 has a unit name, but no reg property

these are just warnings but the output file is actually generated. From this point on, the instructions to enable the overlay are different on BelaMini with respect to the BeagleBone Black.

You should still run the line

cp NEOSEC-TINYLCD35-00A0.dtbo /lib/firmware/

to install the overlay once installed.
On BelaMini (or the PocketBeagle), there is no capemgr , so the overlays can only be loaded at boot. following the instructions here.
This basically means editing the file uEnv.txt in the FAT32 partition present on the SD card and add a line such as

uboot_overlay_addr3=/lib/firmware/ NEOSEC-TINYLCD35-00A0.dtbo 

(make sure you safely remove the disk after saving the file. If this file is corrupted, the board will not boot).

Then reboot the board and the overlay should now attempt to load. You should be able to see in dmesg whether that actually is successful (it doesn't attempt to load for me because I don't have the driver installed). Even if it loads, this is unlikely to work yet, as the pins will have changed between the BeagleBone Black (which the tutorial refers to) and the PocketBeagle.

Next step is finding what pins on the PB are suitable for using this display. Here is a simplified list of the pins available and those used by Bela. We want to pick some pins that are not used by the Bela core (highlighted by a green square and red overlay), and also possibly not touch the Bela digital pins (Dx in the diagram, with a light blue overlay).

SPI: You will still want to use the spi1 bus, because spi0 is used by Bela. This is the one already in use by the device tree overlay, so there is no need to change it there. Pins to be used:

MOSI: P2.25
MISO: P2.27
CLK: P2.29
CS: P2.31

lcd ctrl pins: these seem to be regular GPIOs. P2.05(gpio0_30) and P2.07(gpio0_31) are available, so we can pick those. We need to specify those in the device tree. Replace the lines

				reset-gpios = <&gpio2 16 0>;
				dc-gpios = <&gpio2 28 0>;

with

				reset-gpios = <&gpio0 30 0>;
				dc-gpios = <&gpio0 31 0>;

I am fairly confident this is correct, however there is a note here that says Note the difference in gpio index: gpio1_16 => <&gpio2 16 0>. I don't feel like trusting their advice just now, because they are talking about a kernel/dtb that is at least four year old. A quick inspection of the base device tree suggests that we should use gpio0, but I may be misinterpreting it. If this fails, try to replace gpio0 with gpio1 in the snippet above.

backlight: it seems that this needs a PWM pin. PWM2.B is available according to the diagram on P2.3 . We need to tell the driver to use this pin in the device-tree overlay. The generic documentation suggests that the specific documentation should contain the details of the meaning of the pwms= field, but this is not actually true. Anyhow, I would guess that the right way would be to replace

pwms = <&ehrpwm1 0 500000 0>;

(which was for ehrpwm1A) with

pwms = <&ehrpwm2 1 500000 0>;

but this probably needs to be checked against the driver source.

Note that the above changes only tell the driver which pins to use, but does not actually set the pinmuxer setting for them. Because of how the PocketBeagle works (cape_universal and config-pin, as explained here, the pinmuxer settings are easier to be set at runtime using config-pin (at least for prototyping). So, I'd suggest that for now you shall comment out the lines starting with pinctrl-0 from the device tree and set the pinmuxer settings after boot using config-pin (see below).
Once you apply the modifications above to the NEOSEC-TINYLCD35-00A0.dts file, re-run the dtc and cp lines to compile and install it.

Last, there is one extra gpio needed for the touchpanel. We can use P2.19 (gpio0[27]). According to the guide you are following, in our kernel (4.4) there should be device tree support for the driver for the ADS7846 touch controller (note: I have no idea what this touch controller is). Unless you find a pre-made device tree overlay around that targets your use case, you may well use the modprobe line they suggest, amended to reflect the gpio number you are using (use gpio_pendown=0).

To set the pinmuxer at runtime using config-pin, you will have to run these:

# for the SPI:
config-pin P2.25 spi
config-pin P2.27 spi
config-pin P2.29 spi_sclk
config-pin P2.31 spi_cs
#for the lcd control pins
config-pin P2.05 gpio
config-pin P2.07 gpio
# for the backlight pwm
config-pin P2.03 pwm
# for the ADS7846 (whatever it is)
config-pin P2.19 gpio

I don't have a display like your so I can only do so much from my side, but hopefully this helps you.