Not really. If you have CHR pattern memory to spare, you can keep shifted versions of each sprite to use at the left and upper edges. So if your two-horizontal-sprites object (with anchor point in its top-left corner) is at position X=0, you put sprite A-normal at X=0 and sprite B-normal at X=8, but if the object is at position X=-2, you put sprite A-shift2 at X=0 and sprite B-normal at X=6. Same thing for the upper edge.And since you HAVE to disable both the left and the top 8 scanlines to ever hope of scrolling sprites smoothly in the NES screen (this is a hardware limitation), this makes 4-screen mirroring almost entierely useless.
Of course, you'd have to prepare each sprite eight by eight times for all possible shift positions in CHR-ROM memory if you want one-pixel granularity, which is why I was wondering how CPU-intensive it would be for a CHR-RAM game to create these shifted sprites on-the-fly as they are needed. I could also imagine a custom mapper hardware monitoring writes to RAM at $0200 to detect sprite data that needs to be shifted (for example, by setting one of the unused bits in OAM Byte 2), and automatically providing shifted CHR pattern data when the PPU requests them.