Access itself will not multi-thread your VBA code. To multi-thread, you have to be able to declare thread "forks" and "rejoins" - i.e. places where a separate thread could start or end. Since VBA code is interpretive and the interpreter is not multi-threaded, I think the answer is a definitive NO for VBA multi-threading.
However, we cannot forget that the main drivers of MSAccess(.exe) talk to a compiled database engine that DOES sometimes multi-thread things like read-ahead or write-behind functions, and that can perform queries and manipulate buffers at the same time. Which is why there are DBEngine methods to help you force those threads to synchronize.
If you REALLY got a bit twitchy on this subject, there is still a way but (a) you need to be careful, (b) you need a "hot" machine, and (c) you will need extra memory depending on how you would approach this.
At least in theory, you can write macros that perform a RunCode action. So if you could define your threads in routines to be run via a Macro, there is a chance for you to create a shelled copy of MSAccess running only that macro via the command-line /X:macroname option (and exiting on its own). That shelled copy would be ANOTHER copy of MSAccess running on the same machine, which is allowed (I think). But I've never tried it and cannot remember if that results in two instantiations of Access or only one that time-shares between the two databases.
Note, for example, that you explicitly CANNOT do this type of thing with Outlook. If you have a copy of Outlook already open, you MUST use the extant copy because it has some kind of interlock that blocks you from multi-threading in that case. But I can't speak for whether Access does this. All I can suggest is to try it, run Task Manager to see if you get multiple copies of MSAccess.EXE in memory or not, and thus find out if it is possible to do what you wanted.