No, you need a separate frame sync and separate clock to make this work. You could embed the frame sync and clock in the data stream if you are unidirectional, but this protocol has no way to turn the bus around for RS-485. The difference between RS-485 and other busses is the fact that it is half duplex, bi-directional. The type of interface you are describing does nothing to solve the issues that are part of this interface.
To use time slots you need a master timing control. That is what the sync and clock signals are for. These do not exist in RS-485 and are impractical to add.
So you would add another pair of signals so that all three parties can transmit in their assigned time slot? That is simply not what RS-485 is about.
RS-485 is intended for low end applications (or at least this is the only place I have seen it used) where the number of wires was kept to a minimum. The concept is not hard to understand, it is the implementation using commonly available UARTs that gets messy. The newer MCUs properly support detection of the end of the stop bit so that the bus can be turned around. But many of the older devices still toggle the TxMT flag as soon as the last data bit is shifted out to the pin which is often way too soon.
One way around this is to receive your own transmission. If you have received the last bit of the transmitted word, I would assume that it must include the stop bit to properly flag framing errors. So you can be assured that you have at least reached the middle of the stop bit (at least this is true for the devices I have tested). This is typically good enough timing to turn off the bus driver.