To respond to your example about relocating a file in a SIP-protected area such as /System
and replacing it with a symlink to the relocated file: Yes, in principle, that would work — the symlink will be able to be dereferenced and the intended data will be readable from the user-writable target file. However, there is the potential caveat that whatever generates the specific file may just remove your symlink and replace it with a regular file, thereby undoing your efforts, or whatever reads the file may expect a regular file rather than a symlink, thereby impacting functionality.
To answer your question directly as you've worded it, however: You wouldn't really be "overriding" SIP. The purpose of SIP is to only allow certain tasks to be performed by the kernel, such as writing to certain filesystem locations. By replacing such a file with a symlink to a file that doesn't reside in such a region, you are circumventing the need to be the kernel in order to write data to a place where another process will then read it; but as mentioned before, that process may be designed so that such circumvention doesn't work as you intend.
Ultimately, you should just try it for whatever specific application you're trying to affect and find out the results for yourself.