I am running SQL Server 2012 and I am wondering if I create a clustered index if, as time goes on and users add records, if the RDBMS will maintain the clustered index on table change or have to do something in say for example a daily SSIS task to maintain the index.
There's no difference between a clustered and a non-clustered index from an index maintenance perspective.
If you add rows and they aren't steadily increasing (or decreasing) for the index key, you end up with page splits. Such a page split result in two things:
External fragmentation: When SQL Server follow the linked list do to a scan or partial scan, it will jump back and forth on the disk. This is pretty insignificant with modern disk subsystem (as compared to when we have single spinning disks under our SQL Servers).
Internal fragmentation: After a page split happened, you get two pages which are each about 50% full. A lot of page splits means higher number of of pages. OTOH, when the next row is to be inserted on such a page, there's already space for that row and you don't get a page split at the point in time. Letting the pages average on a certain fill factor can be a good thing, instead of rebuilding the index over and over again, hopelessly trying to reduce internal fragmentation (or even deliberately leaving free space on the pages - end up in the same situation as before the rebuild).
I did some measurement to determine what performance differences I could see between a ridiculously fragmented index (>99%) and an index with 0 fragmentation. I measured them from low to insignificant. The code I was using is also available if you want to run the test in your environment: https://sqlblog.karaszi.com/index-fragmentation-revisited/