If you have a non-production environment, you could simulate your insert / update workload by running SQL Query Stress. Do that before adding the index to get a baseline, and then after to see how much slower it is, and whether that change is acceptable.
In addition to additional overhead for your DUI operations, another consideration is blocking. You might have different blocking patterns than you're used to, since some
SELECT queries will be using the new index, and inserts / updates will have to take locks on that index and the clustered index.
I only point this out to make the point that DUI "overhead" is not the only consideration. Adding indexes can often help with blocking, since SELECT queries on the narrower NC index won't be blocked by updates to other columns in the clustered index.
Without knowing anything about your table, here's a quick walkthrough of what the SQL Query Stress approach might look like. I'll set up a "LogTable" in a new database:
CREATE DATABASE ;
ALTER DATABASE  SET RECOVERY SIMPLE WITH NO_WAIT;
CREATE TABLE dbo.LogTable
Id INT PRIMARY KEY IDENTITY(1,1),
Col1 DATETIME NOT NULL,
Col2 CHAR(4) NOT NULL
Then I use these two queries to simulate the INSERT / UPDATE workload:
-- insert a row
INSERT INTO dbo.LogTable
-- update a random row
SET Col2 = 'val3'
WHERE Id = (SELECT TOP (1) Id
ORDER BY NEWID());
Then I run SQL Query Stress over 6 threads, 250 iterations per thread, with a 100 ms delay between each execution. This completes in about 25 seconds with just the clustered index in place.
Now I'll create a nonclustered index on Col2, which is affected by both the inserts and the updates:
CREATE NONCLUSTERED INDEX IX_Col2 ON dbo.LogTable (Col2);
Running the test again, it took basically the same amount of time (25 seconds). Notice that the logical reads went up, so there is some cost here (it just didn't affect the overall duration).
Of course, this is a very simple case, with no other activity on the "server" (my laptop), so the difference is minimal. But hopefully it demonstrates the concept.