There are a variety of ways to approach #1. Assuming that your requirements are correct (I'd at least double-check them, because they sound weird), what I'd probably do is to create an ApplicationLock table that looks something like this:
CREATE TABLE ApplicationLock (SessionId UniqueIdentifier, CreateDate DateTime, LockType int, Active bit)
Then before you want to do something that requires a lock, check to see if there's an active lock of the sort that would prevent you from doing what you want. (And if there is, see if it's passed some defined timeout period. If it's been longer than some timeout period, you should be able to clear the lock.) If there isn't a lock that would block you, insert your own lock (you can create a SessionId on the Silverlight client with Guid.NewGuid()), do what you need to do, and then clear the lock. If all of this can happen in one web service method call, you should be sure to wrap it in a transaction, so that it will roll back the lock automatically if something fails.
The key is making sure your locks get cleared. If a lock only needs to hang around for one WCF method call, you should be able to handle it in your server-side code pretty easily. However, if they need to persist across method calls, I think you'll need a multi-part strategy. If you're using connection-oriented bindings in your WCF service (like Net.TCP), you can handle the event of the client disconnecting, which would allow you to automatically clear any locks that they've got open. However, I wouldn't depend on this, and I'd have some sort of timeout as a fallback.
For #2 (preventing conflicts when multiple people are editing the table), it depends on what sort of conflicts would be problematic at a business level. If you're just worried about inserting two rows that have the same primary key, there are easy ways around that. Assuming you've got a surrogate key as your PK, you should make that surrogate key either a UniqueIdentifier (e.g., a GUID, which allows you to safely create the key on the client), or you can make it an int/identity column, and then retrieve the value from the table using SCOPE_IDENTITY(). I prefer GUID's, but either would work.
If you need to prevent users from editing values that might have changed underneath them, then you're getting into optimistic vs. pessimistic locking. It's a fairly complicated topic, but you can start here.
On a side note, I mentioned that the requirements sound weird. You should at least look into the various SQL Transaction Isolation Levels, and see if setting any of those would give you what you need.