Nope. There will be operations, like checkpoints, transactions, background processes, but the update itself is neither logged (it's not actually a data modification) nor are the pages dirtied in the process.

Trivial to prove.

CREATE TABLE [dbo].[Test](

[ID] [int] IDENTITY(1,1) NOT NULL,

[Name] [varchar](100) NULL

) ON [PRIMARY]

insert into Test (Name) Values ('Tom')

Checkpoint -- all dirty pages to disk, truncate log

Now, identify the page no of that table's data page (exercise left for the reader)

-- update the row to itself

CHECKPOINT -- just to be sure and to allow for multiple tests

BEGIN TRANSACTION

UPDATE test SET name = name

SELECT [Current LSN] ,

Operation ,

Context ,

[Transaction ID] ,

AllocUnitId ,

AllocUnitName ,

[Checkpoint Begin] ,

[Num Transactions] ,

[Checkpoint End] ,

[Dirty Pages] ,

[Log Record] FROM fn_dblog(NULL, null)

SELECT * FROM sys.dm_os_buffer_descriptors AS bd WHERE page_id = '3783' -- the sole data page for this table

COMMIT

Results:

The log has nothing more than the checkpoint and the begin transaction, there's no LOP_MODIFY_ROW which would be there if the update was logged. (if the query had been after the commit, there's be a LOP_COMMIT_XACT as well). It's the checkpoint, begin and commit which would have caused the log to grow in your test.

The DMV showing the state of the pages in memory shows that the page that the table's sole row it on is unmodified after the update.

Now there will likely be cases where this is not true, but for this trivial case, updating the row to itself neither dirties the page nor logs the update.