I read a few TechNet articles on this question (blank caller name) and came up with a few things that won't have the name in there:
- A device not joined to the domain but triggers a domain lockout (say a workstation that's in a workgroup but logging on to domain resources like file shares by manually typing in username/password at prompts)
- A device not on the local network (e.g. smartphone remotely accessing mail)
- Any other non-Windows systems (Linux/OSX, NAS, proxy, etc)
- Something that doesn't have DNS/NetBIOS resolution
- A lockout from services, instead of an interactive logon
In one thread, someone from Microsoft replied that in order to make it reliable they'd have to do some non-standard stuff... like that's been a problem before? 
Unfortunately the original logon failures happen at the endpoint where they were generated, as you already know, so unless they are failing to a service/server that's on the domain and has local event log coverage, they might be hard to track down. I'd probably run an nDepth search on UserLogonFailure.DestinationAccount = <user that was locked out> to see if I could trace it back, but it's unfortunate that the lockout just doesn't have it.