Well, any version of split that supported single-pass sequences would require buffering anyway (with its Element type being that buffer). There is a bigger issue though:
The more you look at it, the more it becomes clear that the language's current definition of Sequence as single-pass is actually a design mistake, and that any single-pass data sources you have would be much better modeled as an Iterator. The current design exists to support for loops over a data source which destructively consumes its source as you iterate - something which I also think is of dubious utility, and better expressed by while-looping calls to iterator's mutating next() method.
There have been many, many, many, many discussions about this.
So bringing it back to adjacentPairs: for the reasons listed above, I really don't see the point in adding a new generic, lazy, wrapper type just to support this one kind of iteration on this one kind of rare sequence, which everybody seems to agree is a poor API in the first place!
Engineering is all about trade-offs. Consider how simple this pitch would be if it was limited to Collection: A one-line convenience function, easily back-deployable, with no new types or other massive complications. Is it really justified to add so much extra infrastructure just to support single-pass sequences? I think it isn't.