You're right - index rebuild with Standard edition is offline operation (i.e. preventing sessions access the table whose index(es) are rebuilt). Are you really sure the indexes need to be defragmented? You can check the fragmentation with this query:
SELECT S.name as 'Schema',
T.name as 'Table',
I.name as 'Index',
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS DDIPS
INNER JOIN sys.tables T on T.object_id = DDIPS.object_id
INNER JOIN sys.schemas S on T.schema_id = S.schema_id
INNER JOIN sys.indexes I ON I.object_id = DDIPS.object_id
AND DDIPS.index_id = I.index_id
WHERE DDIPS.database_id = DB_ID()
and I.name is not null
AND DDIPS.avg_fragmentation_in_percent > 0
ORDER BY DDIPS.avg_fragmentation_in_percent desc
on 1.3TB DB, it'll take a while to finish the diagnostic query above. You also didn't write what is your biggest table in the DB, (besides other) the size of the table influences the REBUILD times. If the fragmentation on the indexes in question is < 30%, you would be fine with REORGANIZE instead of REBUILD. REORGANIZE is always online operation regardless of the SQL server version.
For the sake of the easier index rebuild, you could also think about partitioning the biggest tables, because you can rebuild individual partitions. However, there are many caveats with partitioning and for the sake of easier rebuild only, I can't recommend it.
Last thing - what is your motivation about defragmenting indexes? If it is performance tuning, reorganization rarely gets you "over the finish line".