Looking at the lstat(2) man page you can get some inspiration on cases that might make it fail with errors other than ENOENT (file does not exist.)
The most obvious one is:
Search permission is denied for one of the directories in the path prefix of path.
So you need a directory you can't search from.
Yes, you can look for one that's already in your system (perhaps
/var/lib/private if it exists?) But you might as well create one yourself, with the equivalent of:
$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile
The lstat(2) operation will fail with EACCES here. (Removing all permissions from the directory ensures that. Maybe you don't even need that much and
chmod -x removing execute permissions would be enough, since execute permissions on a directory are needed to access files under it.)
There's another creative way to make lstat(2) fail, looking at its man page:
A component of the path prefix of path is not a directory.
So, trying to access a file such as
/etc/passwd/nonexistent should trigger this error, which again is different from ENOENT ("No such file or directory") and might suit your needs.
Another one is:
path is too long.
But you might need a really long name for this one (I believe 4,096 bytes is the typical limit, but your system/filesystem might have a longer one.)
Finally, it's hard to tell whether any of these will be actually useful for you. You say you want something that doesn't trigger the "file doesn't exist" scenario. While typically that means an ENOENT error, in practice many higher-level checks will simply interpret any errors from lstat(2) as "does not exist". For example
test -e or the equivalent
[ -e ...] from the shell might simply just interpret all of the above as "does not exist", especially since it doesn't have a good way to return a different error message and not returning an error would imply the file exists, which is most certainly not the case.