GUIDs are readily sortable. But they are not meant for sorting, and if you do so, you cannot rely on a sorted list of GUIDs to match the order of their creation.
The entropy of their pseudorandomness is implementation-dependent, sometimes even hardware-dependent.
Even the UuidCreateSequential
API function's documentation does not promise any sort order to rely on, future implementations may choose to descend instead of ascend, leave gaps, or alternate. Sequence is not the same thing as order.
The strings you create are no longer guaranteed to be unique unless you could enforce that no two timestamps would ever be the same (a good start would be to use four-digit year! remember 2000?)
This is because we do not know where the next GUID will be different from the previous one. If it happens to be in the left part that is overridden by your timestamp, then you could really end up with two identical strings.
One possibility would be to use unique timestamps only. You are free to format those so they look like a GUID and parse into a GUID (for whatever reason). You could use zero padding to fill it up:
{20180413-2213-2490-0000-000000000000}
In the end your question is probably an X-Y problem. Tell us more about what you actually need to achieve, and don't hesitate to add fields, columns, or whatever is needed to achieve both goals: unique keys, and a custom sort order, without compromising the concept of GUID.