Shrinking and consolidating to only one log file
I'd consolidate the log files first, before worrying about the right size to set the log.

To do that, you would need to use the EMPTYFILE clause in a DBCC SHRINKFILE operation, so that the second file can be emptied out and then deleted.

Once you are back to a single log file, you can then shrink right back down to zero (to remove any fragmentation), and then resize it appropriately, to ensure good distribution of Virtual Log Files (VLFs) inside the transaction log file.

There's no way to know what the "right" size is for your log file until you run a normal workload against the database, and see how big it gets. Once you know that, you shrink it down again, and then resize back to that value.

Make sure you set a fixed growth setting appropriate for the performance of your underlying I/O subsystem, and not a percentage file growth. You might want to set it to 100 MB, or 1 GB. It's entirely up to you.

Regarding TRUNCATEONLY, all it does is free any inactive portion, at the end of the transaction log file, back to the operating system. No data inside the log is moved. If there's no inactive portion of the log at the end of the file, no space will be released.

The Simple Recovery Model does not allow point-in-time recovery, but I think you know that. If you want to do point in time recovery, you'll need the Full Recovery Model, and perform regular transaction log backups.