With regard to split BE case and file locking interference, there are layers within layers here. Let's start with how LOCKING works.
Layer 1 - Windows File I/O - if you open two files, you take out two SEPARATE and non-overlapping file locks. Because they are different files and would have to be opened via different file handles, they would not share any internal support structures in common. Disk buffers would not overlap because they are allocated per file handle. There could be MINOR levels of usage contention (NOT locking) for the device if the files are on the same physical disk because neither hard disks nor solid-state disks are multi-threaded under Windows. The device driver linearizes operations for single devices because of the need to keep the I/O context "pure" for signaling purposes. Note that if the two files are on physically different disks, however, the I/O can truly overlap because separate device driver structures are associated with the separate hardware. I.e. each separate device has a separate I/O context.
Layer 2 - Network I/O - Access uses Server Message Block protocols to get files if they require network I/O. For Access, the SMB protocol doesn't go by file; it goes within the file to grab logical blocks within the file. In order to be able to do SMB transfers, you need the file to be opened in order to be able to "map" the file for the purposes of SMB data put/get. (As an aside, SMB isn't limited to files because printers can talk via SMB. User processes can talk to each other using SMB.)
The network-related resources that would become significant would be disk buffers representing mid-file "snapshots." But again, there can be no conflict involved for simultaneous access to the two proposed BE files because they have no disk blocks in common (being from two separate files). Even if SMB used a single buffer set for ALL connections (which it doesn't), the buffers STILL would not overlap, so ... no contention.
Layer 3 - Access Lock File - the contents of the lock file correspond to entries made regarding table locks within a specific BE file. If you have two BE files opened by the same FE, you will have THREE lock files. The FE file and two BE files. And the record-level locking cannot overlap between the two files because their locks are kept separately within the specific lock files.
So - there will be no locking contention between the two files if you went that way. Note, however, that if you go multi-user, two users touching the same file CAN interfere with each other at layers 2 and 3. Access file locks are generally open for shared read/write so represent at most a speed bump. But at layers 2 & 3, buffers are typically opened for exclusive write so in a multi-user environment, you can get blocked. Here is where stuff can get tricky. Access normally blocks by disk buffer, not by record. So for the default case, the interference comes when two users are creating records for the same BE table, because the odds are that both users tried to get to the same place in the BE file, namely the first free block in that file. But they can't both have it simultaneously. Note that this case will have NO BENEFIT from splitting the BE file since you won't split one table across two back-ends. That way lies madness.
You also asked about Relational Integrity in this multi-file context. Colin already noted that you cannot completely enforce relational integrity if you go the multi-file method. I'll amplify that statement.
If you look at the relationship table, it names the table and the field, but it doesn't include a way to name the FILE - i.e. the file containing the table. So if you have two tables in two different Access BE files, they can't see each other because MSysRelationships can't make the cross-file reference. No reference? No relational integrity. And Colin says that the same concept applies to SQL BE files. There, I have to take his word for it.
You asked for info on how relational integrity actually works.
The answer is that in order to have RI, you must establish a relationship. IF you want to establish a relationship you must have an index on the ONE side of the 1/M relationship. (Or BOTH sides of the 1/1 relationship.) So if you have an index, you can make the relationship. When you go to insert a new record in the many-side table, RI can be enforced because Access can look at the relationship to find the field and then look at that field's index in the 1-side table to verify that the value is present.