Perhaps Galera is not the right solution for a very flaky network.
If each Island had its own server that was reliable 'enough', half the problem is solved. Getting the data to (and from) the other Islands needs to be accomplished with application code behind the schemes.
The schema and data flow design would need to avoid various cases where UNIQUE (or PRIMARY) keys could be created simultaneously on separate Islands. UUIDs is one solution, but it does not perform well for huge databases.
Then there is the issue of "stale" data. If the server on an isolated island has "old" data from the other islands, might a user mess things up by acting on that stale data?
Bottom line: Either work on making the network more robust, or stand on your head to make the application robust.
Alternatives...
Circular with more than 2 is really bad. Any outage leaves the rest in an odd state -- some replication is happening, some is not. And if a server actually dies, then it is a big nightmare to repair.
Multi-source replication... Given that you have small databases, and intER-island access is readonly, this could be a good solution. You have one server that is the Slave to all the others. That is, each Island would have a Master, and (when the network is working) replicate stuff to that common Slave. (Is one Island more likely to stay connected?)
All forms of replication/clustering resume replicating and pretty quickly "catch up" after the network comes alive again.
As for UUIDs
versus AUTO_INCREMENT
-- If all writes to any particular table and all related tables are only coming through the one Island's server, then I don't see a need for UUIDs.
(Anyway, with only 100MB/island, UUIDs probably won't fall off the performance cliff.)