Hi Anil,
I now believe the "by Unpin" flushes are due to interaction with the checkpoint process. The checkpoint process runs regularly and flushes all dirty buffers in cache to disk. Some of those dirty buffers may still be pinned to transaction log records in the user log cache (ULC, sometimes also called private log cache or PLC). Since ASE uses a write-ahead log, those log records must be flushed to disk before the data page they are pinned to is flushed. So to unpin the dirty data page buffer, the checkpoint process has to force the ULC of the spid creating the index to flush.
I wasn't originally seeing any Unpins because I was working with a single engine server with a much smaller table and the create index was completing in a few seconds. Once I started using a multi-engined server (to allow more concurrency between the checkpoint process and the create index spid) and your DDL with enough randomly generated rows that create index was taking more than a minute, I started seeing some Unpins.
You could perhaps reduce the Unpins by setting the sp_configure parameter "recovery interval in minutes" to a very large value, so that checkpoint will execute less frequently. Note that the name of this parameter is misleading. ASE uses a hardcoded value for the number of transactions that would result in a minutes worth of recovery time, the value was picked a long time ago and systems are much faster now. [Also, long-running transactions can cause recovery to take much longer than the configured value in minutes]. So if you want to play with this, set "recovery interval in minutes" to the maximum value of 32767 and see how that affects Unpins and the time to create the index. My guess is that the effect of reducing or eliminating the Unpins won't be significant, and you should set the value back to the default of 5. However, if it is beneficial, you might temporarily set this high during your create index process.
-bret