When working from a single office, I have in the past defined a shared area as a nominated "binary repository".
The rules for the binary repository are that everything is versioned by filename and so a given file never changes - if you need to change a file you copy it and give it a new filename. Then you don't need locks. The versioned build script in the git repository finds the binary repository from an environment variable. This way old revisions in the git repository that depend on old binaries still work, but there is full visibility to delete old versions in the binary repository to free up space as required.
I used this kind of arrangement for things like upstream tarballs which changed relatively infrequently. I'm not sure how well this would work for you though.
One thing I think you might want is the ability to rebuild any revision out of your repository. Any revision control system achieves this, but if your build depends on binaries that aren't "in" the git repo, then how would this work?
If you still want some way of locking binaries, then there is an immediate question: how and when are files locked and unlocked? Manually (like SourceSafe)? Automatically on file open?
I would reconsider whether you want the binaries in the source tree or just running parallel alongside it. If they're not managed by git, then being in the source tree would cause confusion, wouldn't it?
For manually locked binaries, you might find a suitable WebDAV server useful, perhaps? The protocol supports locks. Maybe something built on git hooks and WebDAV with a central binary repository will work for you.
For automatically locked binaries available and modifiable across multiple offices, take a look at Synctus (my product). I'm not clear if this would be useful to you though.