It's unportable, and insecure -- arguably operating through a security hole that some think shouldn't be permitted. It introduces the possibility for new and interesting bugs inside the open() call itself. And if making system calls lie to the application seems like the best solution, it's either a really badly designed application, or an application restriction that wasn't intended to be circumvented, or just a solution that needs more thinking through. There's almost always a better way, even if it means fixing the broken app.
Also consider the sheer number of system calls that might need trapping. Is open() really the only system call your application needs? what about stat(), unlink(), and the dozens of other system calls that need a filename. It's not as "easy" as it looks on first blush. I tried writing something like this to overload gettimeofday() to make programs run "slower". It worked, sort of, but we found more and more time-related calls which needed to be trapped to work right. Eventually I realized I needed to trap and deal with the hardcoded asm timing-related things in pthreads itself, and gave up. Stuff that alters how kernel calls operate that drastically belongs in the kernel.
One after-the-fact fix I see done with it is
libkeepalive, to set TCP keepalive intervals by default whenever a program calls socket(). Since nearly no programs have the ability to do so themselves, and you'd hardly want to set keepalives on every single socket in your system, it can be handy. It's also relatively easy, since it only needs to trap exactly one system call -- socket().
And you haven't explained what your actual goal is, either. Until you do I'm not convinced this would be the best way.