Yes, it is very common (and sometimes very useful) to have different stuff in the subscriber database than the publisher.
To be clear, though, SQL replication is normally used to only push data (contents of tables and/or views), not to push functions and stored procedures.
I'm not even sure it's possible to use Replication to keep functions/stored procedures in sync between databases, you'd probably have to use database-level triggers or something, or just manually script them out and create them on the other side.
A few tips:
- You can create different indexes on the destination tables, if necessary (this is very common when the subscriber is used for reporting). These will be dropped if replication is ever re-initialized, though, so you'll need to script them out beforehand.
- Don't ever try to change columns or structure of a replicated destination table, you'll break things. If you need extra columns, make a new table with a 1-1 relationship. If you need different data types, fewer columns, or other changes, make a view.
- If you need to change the data in the destination tables, and views aren't cutting it, then make a scheduled process that copies/transforms the data into other tables in the destination database.