Can I safely utilize `dd` to backup my drive to a singular image file?

it is indeed a bit redundant, because this has been said in answers to other questions. However, I couldn't find one that stated this explicitly.

Yes, you can.

It's not a good method of making a whole-disk backup, though. dd really makes little sense if you're backing up a whole image, and will tend to be slow (as it dictates a block size that might interfere with physical read sizes). Also, at least as demonstrated in your command line, you'll probably end up generate a large output file full of zeros that needn't occupy space, but do. You can achieve the same as you do with dd here with cat /dev/nvme0n1 > backup.img, or if you want progress reports, pv -o backup.img /dev/nvme0n1, both of which might realistically be faster than dd. Don't use dd unless you need its seeking and conversion facilities (it's a common "traditional tool", and commonly is the wrong tool for the job).

If you just want a quickly-generated image that you can restore later on easily,

zstd -T0 -8 -f -o backup.image.zst /dev/nvme0n1 

creates an on-the-fly compressed image. Advantage of that is space saving, and as a side effect of that, higher speed (because your SSD will be much faster at reading than your backup place at writing). Reconstruction would take zstd --sparse -d -f -o /dev/nvme0n1 backup.image.zst.

If you instead need something that you can still use in a VM to inspect the state of your system, while making snapshots to make sure you're not accidentally deleting any data while running the VM:

qemu-img convert -f raw -O qcow2 /dev/nvme0n1 backup.qcow2 

gives you a qcow2 image, which you can use directly as disk image in libvirt/qemu VMs, e.g. the ones you can set up using virt-manager.

I need to ship the SSD back to my warranty provider, but I should be able to restore it to a drive of the same or greater size once it is repaired.

I cannot imagine an SSD getting "repaired". It'll either get diagnosed as "OK" and get sent back to you, or you'll get a new one. Only thing I could imagine would be getting a firmware update on the fly, but that would be the same that you could do locally.

In either case, unless encrypted, you shouldn't send your data out to the world, so I'd recommend blkdiscard /dev/nvme0n1 after taking the backup, before shipping out the disk. Note that this irrecoverably removes the data. (At least as well as overwriting the disk would.)

This probably comes a bit late, but nevertheless for completeness' sake:

You may want to reconsider if a full image is really what you want for your usecase. Restoring from a disk/partition image recreates the exact filesystem layout, including fragmentation and any other garbage that builds up during the lifetime of a filesystem. If you instead back up the data (not the partition), and then dump it on a newly formatted filesystem, you get the same contents, neatly arranged at the start of the filesystem, with the free space as one contiguous region at the end. Yes, fragmentation is not that big of an issue for SSDs as for HDDs, but continuous reads/writes are still faster than random access.

So unless you want to do forensics and other low-level stuff (recovering deleted data, etc.), for 95% of practical purposes a plain old tar -cJf <partition root> (or with --zstd if you prefer) will give you the same data, decently compressed and "sparsified". The only overhead is that you'd need to repartition the new drive before restoring, but this has the added flexibility that you can partition it in a different way than the original.

With legacy MBR bootable drives, creating an image has the slight advantage that it restores the boot loader in the MBR, so you don't need to install it again when restoring. With EFI-based boots, even that is not valid anymore, since you can restore the ESP by simply unpacking an archive.

The whole thing is of course valid only for more-or-less Unix native filesystems like ext[234] and vfat (not native, but simple enough). If you have an ntfs partition, then using either ntfs-specific tools, or indeed a raw image, might be simpler.