Inserting few millions of rows: Does indexing happens along with the insert operation
Everything will be populated on insert, it is also one of the reasons why having too many indexes is considered bad practice on tables that have a lot of CRUD operations.

In your case, you only have a CLUSTERED and a NON CLUSTERED index (SQL Server creates a CLUSTERED index for a PK by default even if you don't specify it). Non clustered indexes have something called a "clustering key" which is basically a pointer to the clustered index. 

A clustering key consists of the values of the clustered index keys from the row being pointed at and the Uniquifier (if present). With every insert, the clustered key has to sort the values in memory, and in turn each one of those pointers have to move. 
Also keep in mind that clustered indexes in SQL Server immediately make the table a B-Tree structure (unless it's a column store index), and this is one of the biggest causes for fragmentation. As the rules of the B-Tree data structure could force pages to split and therefor change the entire structure of the B-Tree (it's like a cascading effect).

In order to avoid some fragmentation on insert, you should sort the data with a query before doing so. This post explains how it works and why.

Fun fact, a nonclustered index will point at something called an RID (Row Identifier) when no clustered index is present. This is then called a heap table.